Предоставляет ли Windows какой-либо API-доступ к HPET?

Question

В настоящее время мне интересно использовать таймер HPET, чтобы получить время разрешения в микросекундах. Похоже, что информации об использовании этого устройства в Интернете очень мало. Я нашел информацию , что Linux предоставляет драйвер HPET и есть пример в источнике , демонстрирующего режим API пользователя, и старый список рассылки нить , которая , кажется, указывают есть (был?) В режиме ядра API для его использования , а также, но мало документации за пределами этого.

Пока мне не удалось найти никакого эквивалента для драйвера Windows HPET. Предоставляет ли Windows своего рода интерфейс, пользовательский режим режима ядра для доступа и использования HPET на платформах x86? Google подводит меня здесь, поскольку кажется, что он более или менее наводнен сообщениями на форуме и статьями, в которых спрашивается о включении / отключении HPET по соображениям производительности.

Answer 1

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

Например; вы получаете «файлы» (и вам не нужно заботиться о SCSI против SATA против NVME; или FAT против NTFS против чего-либо еще) и «сокеты» (и вам не нужно заботиться о проводном Ethernet против WIFI против бесконечной полосы против чего-либо еще), и «потоки» (и не нужно особо заботиться о буквальных процессорах) и «виртуальная память» (и не нужно заботиться о реальной физической ОЗУ).

Таким же образом; каждая ОС будет предоставлять какой-то высокопроизводительный / высокоточный API таймера. Этот API может или не может использовать HPET внутри (но у вас нет причин беспокоиться о том, использует он или нет, потому что вы не хотите, чтобы сломанный код постоянно ломался).

Для современных систем 80x86; этот высокопроизводительный / высокоточный API таймера, скорее всего, будет использовать TSC ЦП и локальный таймер APIC (потому что он лучше / точнее / меньше накладных расходов) и не будет использовать HPET. Для очень старых компьютеров 80x86 он, вероятно, будет использовать PIT (просто потому, что лучшие варианты, включая HPET, не существуют в оборудовании). Для других архитектур (ARM, Sparc, PowerPC, ...) тот же API будет использовать все, что действительно имеет смысл для этой архитектуры.

По сути; если существует какая-либо ОС, которая предоставляет прямой «неабстрактный» доступ к базовому устройству HPET; тогда эта ОС представляет собой хрупкий беспорядок, который не справился со своей работой, и от нее следует как можно скорее отказаться.

Для Windows; API состоит из 3 частей:

а) метки времени высокой точности ( QueryPerformanceCounter(), GetSystemTimePreciseAsFileTime()). Обратите внимание, что они могут быть намеренно «ослаблены» по соображениям безопасности (чтобы немного усложнить синхронизацию атак по побочным каналам, потому что TSC ЦП слишком хорош).

б) Высокая точность выдержек времени ( Sleep(), Ожидаемые объекты таймера - см. Https://docs.microsoft.com/en-us/windows/win32/sync/waitable-timer-objects ).

c) События с «достаточно высокой» точностью времени ( SetTimer() и WM_TIMERсообщения - см. https://docs.microsoft.com/en-us/windows/win32/winmsg/using-timers ). Обратите внимание, что точность здесь не должна быть высокой (например, наносекундная точность), потому что задержка доставки сообщения (например, как долго сообщение находится в очереди, ожидая его получения, пока вы обрабатываете другие сообщения) сделает «чрезмерную точность "в любом случае непригоден.