Читал про 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
и чтобы эта частота не менялась динамически