наверное, я тут соберу все возможные глюки систем пока я пишу свой проект!
какой-то очередной затык, на этот раз с таймерами...
в результате экспериментов выползла весьма странная, на мой взгляд, проблема:
написан тестовый бустовский поток, работающий с прерываниями (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

видимо, всё-таки проблема в реализации...

Почитай еще здесь
http://lists.boost.org/Archives/boost/2002/06/31205.php
http://www.ddj.com/windows/184416651
http://msdn.microsoft.com/en-us/magazine/cc163996.aspx
Иии если будешь думать про RDTSC имей ввиду, что там много своих подводных камней.
Резюмируя - единого решения нет.

Но лучше RDTSC навряд ли можно что-то накопать... нуууу почти навряд ли.
18.11 Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3B: System Programming Guide, Part 2
http://download.intel.com/design/processor...uals/253669.pdf

Сообщение отредактировал Andrew Selivanov - 20.3.2009, 14:10

м-дя... что-то совсем грустно, что нет единого решения для такой нехитрой задачи, как обычный таймер. так хотелось сделать общую софтину без ifdef'ов и всяких ухищрений машинно- и системно-зависимых...
умилил вопрос в статейке: Why would you be interested in obtaining the system time with a resolution below one millisecond?
блин, у меня в рабочих машинах миллисекунда - это целая вечность, а за 10 миллисекунд вообще физические девайсы могут поломаться, если вовремя не отловить и не обработать критическое событие...
определённо, венда - не RT система: на уровне драйверов я наблюдала задержки вызова обработки немаскируемых прерываний до 200 микросекунд, теперь вот это ракообразие реализации системного таймера на верхнем уровне...
придётся сесть и написать отдельный модуль с таймером для венды.
но всё-таки интересно узнать, что об этом разработчики буста думают. в багах у них нет такого пункта. но 15-миллисекундный квант в реализации таймеров для потоков - это если и не бага, то просто ужоснах какой-то. вполне возможно, что имеет смысл доработка буста в этом плане, тем более, что она возможна.

В Boost-e я так понимаю тупо используется GetSystemTimeAsFileTime, т.е. навряд ли это бага Boost-a (хотя кто знает)

см ../datetime/microsec_time_clock.hpp

Кстати ты прочитала ответ Кемпфа в первой ссылке за 2002 год? (и последующий тред?)


Что в переводе как я полагаю "и не ...волнуют меня ваши виндовые проблемы"

тут не про xtime речь. xtime - это маленькая "самопальная" реализация таймеров в библиотеке thread. она действительно маленькая, простенькая и примитивная. там один файл реализации и две-три служебные функции. однако thread поддерживает работу синхронизации по всем видам таймеров, включая общие бустовские таймеры ptime из date_time. и вот date-time - это уже серьёзная библиотека, в которой они попытались создать универсальный набор утилит для работы со временем и таймерами. она развивается и вполне вероятно, что её можно укомплектовать некоторыми наворотами по уточнению работы со временем в венде. ведь там даже есть работа с наносекундными интервалами в 64-битных системах. я её не тестировала, но теортетически она как-то работает и явно не через тормозной вендозный системный таймер! почему бы не поковыряться и для 32-битных систем...

Ты внимательно мой пост посмотри... я про xtime не говорил. Именно в ../datetime/microsec_time_clock.hpp и есть тормозной системный таймер и пачка дефайнов / workarounds

/*! @file microsec_time_clock.hpp
  This file contains a high resolution time clock implementation.
*/
...
    //! Return the local time based on computer clock settings
    static time_type local_time() {
      FILETIME ft;
      #if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3205))
      // Some runtime library implementations expect local times as the norm for ctime.
      FILETIME ft_utc;
      GetSystemTimeAsFileTime(&ft_utc);
      FileTimeToLocalFileTime(&ft_utc,&ft);
      #elif defined(BOOST_NO_GETSYSTEMTIMEASFILETIME)
      SYSTEMTIME st;
      GetSystemTime( &st );
      SystemTimeToFileTime( &st, &ft );
      #else
      GetSystemTimeAsFileTime(&ft);
      #endif
      return create_time(ft, LOCAL);
    }
    
    //! Return the UTC time based on computer settings
    static time_type universal_time() {
      FILETIME ft;
      #if BOOST_WORKAROUND(__MWERKS__, BOOST_TESTED_AT(0x3205))
      // Some runtime library implementations expect local times as the norm for ctime.
      FILETIME ft_utc;
      GetSystemTimeAsFileTime(&ft_utc);
      FileTimeToLocalFileTime(&ft_utc,&ft);
      #elif defined(BOOST_NO_GETSYSTEMTIMEASFILETIME)
      SYSTEMTIME st;
      GetSystemTime( &st );
      SystemTimeToFileTime( &st, &ft );
      #else
      GetSystemTimeAsFileTime(&ft);
      #endif
      return create_time(ft, GMT);
    }

2 Iron Bug Таки посмотри на Erlang - он даёт soft real time.

Не... Думаю, не канает. Две причины: во-первых - виртуальная машина... нафиг надо ещё интерпретаторы - я по скорости на Си с полной оптимизацией едва укладываюсь иногда... А вторая - строгая изоляция процессов в Erlang, а у меня общих данных просто дофига - и все процессы(потоки) должны иметь к ним доступ. Так что думаю, всё-таки старый добрый Си. Ну, и ++ иже с ним, я их особо не разделяю, ибо на чистом Си практически не пишу последнее время, только изредка для контроллеров разве что.
Я думаю, пока что просто буду копаться и писать ifdef'ы для венды вместо буста, чтобы обойти ограничения таймеров. Если время будет - посмотрю реализацию date-time: насколько сложно туда внедрить обход этого тормозного "системного таймера". Если можно - то буду писать разработчикам буста. Просто так писать нет смысла - надо сначала поглядеть, какая там ситуация с таймерами и можно ли её улучшить.

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

Для винды есть мультимедийный таймер. (About Multimedia Timers) Он вроде как даёт заметно большую точность чем обычный.

Но таки лучше не использовать десктопную винду для реалтайма.

Сообщение отредактировал Tonal - 31.3.2009, 11:12