Читал про QueryPerformanceFrequency, QueryPerformanceCounter, но ничего полезного из этого не вышло.

Код моего таймера на C# для данного простоя таков, что эти самые микросекунды нормально отсчитываются в огромных кол-вах... вот, собственно, и код:



P.S. не советуйте, пожалуйста QNX и т.п., мне нужно считывать данные с LPT с минимальным простоем между запросами 4 мкс (Win9x/NT), переключение между процессами блокирую так:
Process.GetCurrentProcess().PriorityClass = ProcessPriorityClass.RealTime;
Один не очень авторитетный программист сказал, что запрос на чтение данных с LPT занимает 1 мкс, во что я не очень верю. Пробовал Thread.Sleep(new TimeSpan(1000)) , но в MSDN прочел, что малые простои игнорируются, и это будет как Sleep(0), но и это лишь гарантия минимального простоя, максимальный при этом неизвестен, к тому же таймер посылает сообщения лишь каждые 55 мс(насколько помню)... внешние устройства пожалуйста тоже не советуйте, только программно. СПАСИБО. -> может можно както более грамотно создать dll на с++ и импортировать...

Sleep(0) - не игнорируется, это просто переключение контекста, вообще, ОС с вытесняющей многозадачностью для вашей задачи не очень здорово подходит =)

Benassi, а ты разделом не ошибся? С# тут вроде как не очень обсуждают. Тебе лучше в .NET обратиться. Хотя, думаю, тебе и там не помогут.

Только-что обратил внимание, 
АФАИК это вообще невозможно =)

Ну, в юниксах есть msleep, и даже nanosleep . Но это юниксы. В виндах - сложнее 

в винде это тоже возможно (WaitFor... + Eventы), но т.к. что Win, что nix - это ОС с вытесняющей многозадачностью, гарантируется только то, что поток будет спать не меньше указанного времени.

просвети пожалуйста как, Wait функции принимают милисекунды, а нужно микро
на точность менее чем 50 микросекунд рассчитывать не стоит из-за архитектуры ОС

Добавлено через 8 минут и 1 секунду
можно почитать здесь

че-та я уже запутался...
милисекунда это 1/1000
микро это 1/1000000
а наносекунда это скока?
организовать вэйт можно до сотен наносекунд... сейчас поищу...

Это сообщение отредактировал(а) korian - 3.4.2008, 16:14

сам вызов системного сервиса может занять и того больше времени

даже теоретические расчеты показывают, что это невозможно
возьмем, к примеру, двуядерный процессор C2D с пиковой частотой ядра ~2.5Ghz
2.5 * 2 ^ 30 тактов в секунду = 2.5 * 2 ^ 30 / 1 * 10 ^ 6 ~ 2684 тактов в микросекунду
в среднем за такт выполняется 4 микрооперации => за микросекунду может выполниться ~671 микроопераций
усредненное количество микроопераций в одной инструкции ~3 => за одну микросекунду в среднем выполнится 223 инструкции
а теперь рассмотрим путь от вызова nanoslepp()/msleep() до запуска таймера
количество инструкций в разы превышает число 223 (можете проверить)
кроме того, есть еще кэш-промахи, работа MMU, штрафы за непредугаданные переходы и т. д
все это значительно уменьшает реальное количество инструкций, которые могут быть выполнены за 1 мк

если даже предположить, что время выполнения всех инструкций до запуска таймера значительно меньше 1 мк, то тут возникает другая проблема: что делать со временем, которое понадобится для обработки аппаратного прерывания, возможного перевода процесса в состояние готовности, ожидания выбора его планировщиком, перключение контекста и возврат на третье кольцо?

Добавлено @ 16:15

10^-9

Это сообщение отредактировал(а) MAKCim - 3.4.2008, 16:16

вот пример, там правда ожидают 100000000 сотен наносекунд (10 секунд). кароче деление 100 наносекунд.
http://msdn2.microsoft.com/en-us/library/m...008(VS.85).aspx

Это сообщение отредактировал(а) korian - 3.4.2008, 16:26

если точность указывается до 0.1us, это не значит, что реально она соблюдается, вряд ли можно сделать так, что-бы какой-то твой код на современном железе отрабатывал с частотой 1 MHz =)
для этого есть DSP процессоры

MAKCim, хорошо, верю, но на кой фиг тогда сделали nanosleep? более того, вызовы sleep и msleep, кажется, просто вызывают nanosleep, не так ли? 

Господа, таймер виндовс посылает сообщения системе 1 раз в 55 милисекунд, то есть если я захочу добиться простоя в цикле 1000 раз по микросекунде, это будет гораздо больше. Мне не нужно переключение между процессами, нааборот, моя программа работает с приоритетом реалтайм,
может кто-нибудь может выложить функцию, проверенную им, не содержащую Sleep(0)?

Хотелось бы рассчитать функцию wait(microseconds), которая зависела бы от процессора, используя RDTSC или QueryPerformance, минимальный простой (не Sleep а while();) у меня должен быть 4 микросекунды.



Минимальные простои игнорируются(читайте выше), хочется зависеть от апи.

это понятно, об этом писалось выше и не одним человеком... скажем так, точность в том, что если ждать надо (1 секунду + 500 наносекунд) - то точности можно добиться. хотя всеравно нельзя, т.к. ОС с вытесняющей многозадачностью. (можно поидее, если поток реалтайм и других реалтайм потоков нету + еще устройства не посылают прерываний   и еще многа чего)


извените конечно, но таймер по Sleep и WaitableTimer это две большие разницы.

Добавлено @ 17:24
и while(); от WaitableTimer сильно отличаться не будет, даже если вы найдете вариант посчитать количество итераций для while.
но гарантировать это время всеравно никто не сможет, т.к. какой-нить жесткий диск, запнется на своем блине и повесит всю систему на пару секунд.

Это сообщение отредактировал(а) korian - 3.4.2008, 17:35

т. е как видишь, семантика не нарушается

почему сделали?
вполне возможно с расчетом на будущее
может когда-нибудь это станет возможным на обычных (не специализированных) десктопных процессорах
кроме того, юниксы (а nanosleep() специфицирована в POSIX.1-2001) бегают много где (и встаиваемые системы, и RT-системы, ...)
возможно в одном из этих мест nanosleep() отрабатывает свое название  

Добавлено через 10 минут и 53 секунды

с асинхронными событиями даже RDTSC не справится
другое дело, замаскировать все, что можно замаскировать
но из 3-го кольца без специального API это не сделать
кроме того, чтобы RDTSC использовать, нужно точно знать частоту инкрементации счетчика TSC
и чтобы эта частота не менялась динамически

не повесит   

это почему? поидее смотря на чем запнется...

так это проблема контроллера диска
если запнется - возвратит ошибку
"запинание" не влияет на процессор 

на процессор - нет, а на процессы - влияет (если они работают с диском, а они все работают с диском).
конечно, существует куча вариантов, когда оно не зависнит, но приведенный вариант из начально "если".
вариант, когда вся система повиснит из-за тормазов на диске существует, также как существует вариант, когда написанный таймер будет отсчитывать ровно 1 мкс (когда в системе всего один поток и нет переключений на обработку прерываний, этого добиться можно).
если уж на то пошло, пусть диск работает через PIO, тогда будет влиять и на процессор.

Это сообщение отредактировал(а) korian - 3.4.2008, 19:35

отнюдь

таймер то отсчитает без проблем, но когда мы получим уведомление об этом, общее количество микросекунд будет далеко не 1

учитываешь обработчик самого прерывания по таймеру?

если произошла ошибка, не важно DMA используется, или PIO

Добавлено через 4 минуты и 47 секунд

если текущий процесс не выполняет операции I/O, а он не выполняет, т. к

по определению, операции I/O реализуются через read()/write()

то на этот процесс диск не влияет
переключение контекста да, диск - нет

на сколько я знаю, на x86, все прерывания можно отключить, включая таймер (может ошибаюсь...)
если делать таймер через for(int i = 0; i < n; ++i) ; то управление вернет сразу после того как пройдет 1 мкс.

и вообще не вижу смысла в споре... или вы считаете, что не может быть варианта, когда зависание диска приведет к зависанию всей системы?

Товарищ, извини, но я железно знаю пример, когда жёсткие диски отвалились (хардварно), а система (GNU/Linux) продолжала работать, и, более того, обрабатывать сетевые запросы. Так что мимо.

это тут не причем. перечитайте вопрос.
я не говорил, что при любом зависании диска вся система полностью зависает.

Это сообщение отредактировал(а) korian - 3.4.2008, 21:34

korian, 

JackYF правильно пример привел
он показывает, что правильно спроектированная система не завалится при неполадке с блочным устройством
остальные в виду их дефектности не рассматриваем


Это сообщение отредактировал(а) MAKCim - 3.4.2008, 22:08

опять же, вопрос о том, что система должна завалиться не рассматривался, она должна запаузиться на некоторое время.

Тема-дубликат, закрываю.