crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

> boost::ptime - реальные интервалы на разных системах, странная проблема с таймером под вендой
Iron Bug
  опции профиля:
сообщение 20.3.2009, 13:12
Сообщение #1


Профессионал
*****

Группа: Модератор
Сообщений: 1611
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 219 раз(а)




Репутация:   12  


наверное, я тут соберу все возможные глюки систем пока я пишу свой проект!
какой-то очередной затык, на этот раз с таймерами...
в результате экспериментов выползла весьма странная, на мой взгляд, проблема:
написан тестовый бустовский поток, работающий с прерываниями (thread::interrupt()), c условными переменными (conditional_variable) в качестве синхронизации и с таймерами (timed_wait), работающими с этими переменными. в качестве временных интервалов для таймеров использовался позиксовский ptime, реализованный в бусте как часть date_time библиотеки.
вообще, у меня была идея проверить совсем другие вещи, но в итоге получился такой интересный вывод про таймеры: запускаю тест дома под линюксом - минимальный интервал срабатывания timed_wait - примерно 50 микросекунд. при риал-тайм приоритете даже до 10 можно довести, а в худшем случае при загрузке системы - ну максимум 200 задержка может быть (это десктопный вариант дебиана с 26 ядром).
а вот под вендой XP Pro на работе та же прога даёт минимальный интервал аж в 15625 микросекунд - и это вообще без нагрузки на систему!
это что, такие тормоза системного таймера в венде или я чего-то недопонимаю в реализации??? может, ptime не самый быстрый таймер в бусте? (я использую microseconds интервалы).
я понимаю, что венда - не риал-тайм система, но неужели всё настолько плохо или это всё-таки реализация подводит?


копалась в сети, вот чел на ту же самую проблему напоролся:
http://www.nabble.com/-date_time--Timer-an...td21884194.html

видимо, всё-таки проблема в реализации...
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
2 страниц V  < 1 2  
Начать новую тему
Ответов (10 - 11)
Iron Bug
  опции профиля:
сообщение 31.3.2009, 13:56
Сообщение #11


Профессионал
*****

Группа: Модератор
Сообщений: 1611
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 219 раз(а)




Репутация:   12  


пасип. может, пригодится! :)
как раз вот копаю, ищу варианты, как лучше сделать таймеры... если ковырять буст, то надо же для всех систем чтобы работало... а мультимедия таймеры только с 2К и выше. ну даже если наплевать на 95 и иже с ним, то всё равно не так всё гладко выходит. от потоковой библиотеки растёт много чего и её изменение - дело весьма мерзопакостное.
а про венду... ну так это и ежу понятно, то не риал-тайм она ни разу! надеюсь, скоро это поймут не только наши программисты, но и начальство :) просто когда-то всё начиналось с распределённой архитектуры и все скоростные задачи выполняли платы контроллеров, а сейчас пытаются перейти на обработку всех данных на компе, что на венде нереализуемо, вообще говоря. на самом деле на рабочих машинах у нас не десктопная, а эмбеддед венда, это я тесты гоняю тут на ХаРэ... но не суть. разницы мало. у эмбеддед единственный плюс - попытка скопировать у линюкса идею о модулях ядра и на этом усё... по скорости та же фигня, просто можно убрать лишние модули при установке системы. ну, на сколько-то это ускоряет работу, уменьшает ядро, но принципиально это та же венда.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Andrew Selivanov
  опции профиля:
сообщение 2.4.2009, 17:49
Сообщение #12


Участник
**

Группа: Участник
Сообщений: 249
Регистрация: 9.10.2007
Из: Москва
Пользователь №: 3

Спасибо сказали: 15 раз(а)




Репутация:   6  


Цитата(Iron Bug @ 31.3.2009, 11:23) *
вот, пока копала буст и точные таймеры...
выяснилось, что проблема не только в них. точнее, если бы только в них! я первым делом прикрутила быстрые таймеры к date_time. это только заголовочники, так что тут сложностей не было. но тут вылезли другие "цветочки": потоки... все слипы, вся синхронизация потоков сделаны через вендозный Sleep и WaitForSingleObject, а там.... там миллисекунды! :ireful: (тут бы надо подвесить кое-кого за кое-что, но об этом умолчу). Можно сделать более хитрожопо, через объекты ядра, но будет жрать больше ресурсов и возни там не на один день и возможно даже не на месяц, если капитально всё переделывать. более того, если копать дальше, то эти геморройные миллисекундные функции вылазят в межпроцессной библиотеке - теоретически, если уж править, то и там тоже надо всё перекапывать.
так что пока что у меня миллисекундная задержка осталась при синхронизации потоков и слипе. понятное дело, откуда - из реализации вендозных функций, заюзанных в потоках.
покопаюсь ещё, если не задолбает - буду потихоньку дорабатывать библиотеки, но хрен знает сколько времени это может занять, тем более что код не мой. я теперь понимаю, почему господин Кемпф не хочет с этим связываться!


Думаю тов. Кемпф уже дофига чего сваял, за что ему (нет, не "респект и уважуха" :) ) большое спасибо. Вообще Boost толковая библиотека, но вот потоковая её часть вообще малость урезана. Смутное что то из творений Борланда вспоминается и там вроде с потоками было много намучено. Да и тот же MFC давал некий простор...

PS: Я немного не понял, что значит объекты ядра, Zw функции? Так это же всё через драйвер, а здесь нас поджидает ж0па <_<

PS: В M$ вообще можно сказать недавно RND поменяли образца хз какого года... http://www.computerworld.com/action/articl...ticleId=9048438
Так что Boost еще куда ни шло :)

Сообщение отредактировал Andrew Selivanov - 2.4.2009, 17:52
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

2 страниц V  < 1 2
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0


RSS Рейтинг@Mail.ru Текстовая версия Сейчас: 15.7.2025, 13:58