Как заставить поток спать меньше миллисекунды в Windows

Это указывает на неправильное понимание функций сна. Передаваемый вами параметр - минимальное время для сна. Нет гарантии, что поток проснется точно в указанное время. Фактически, потоки вообще не «просыпаются», а выбираются для выполнения планировщиком ОС. Планировщик может выбрать ожидание намного дольше, чем запрошенная продолжительность сна, чтобы активировать поток, особенно если другой поток все еще активен в этот момент.

Как говорит Джоэл, вы не можете осмысленно «спать» (т.е. отказываться от запланированного CPU) в течение таких коротких периодов времени. Если вы хотите отложить на какое-то короткое время, вам нужно вращаться, неоднократно проверяя таймер с подходящим высоким разрешением (например, «таймер производительности») и надеясь, что что-то с высоким приоритетом все равно вас не упустит.

Если вы действительно заботитесь о точных задержках в такие короткие промежутки времени, вам не следует использовать Windows.

Используйте мультимедийные таймеры с высоким разрешением, доступные в winmm.lib. См. Пример this.

#include <Windows.h>

static NTSTATUS(__stdcall *NtDelayExecution)(BOOL Alertable, PLARGE_INTEGER DelayInterval) = (NTSTATUS(__stdcall*)(BOOL, PLARGE_INTEGER)) GetProcAddress(GetModuleHandle("ntdll.dll"), "NtDelayExecution");
static NTSTATUS(__stdcall *ZwSetTimerResolution)(IN ULONG RequestedResolution, IN BOOLEAN Set, OUT PULONG ActualResolution) = (NTSTATUS(__stdcall*)(ULONG, BOOLEAN, PULONG)) GetProcAddress(GetModuleHandle("ntdll.dll"), "ZwSetTimerResolution");

static void SleepShort(float milliseconds) {
    static bool once = true;
    if (once) {
        ULONG actualResolution;
        ZwSetTimerResolution(1, true, &actualResolution);
        once = false;
    }

    LARGE_INTEGER interval;
    interval.QuadPart = -1 * (int)(milliseconds * 10000.0f);
    NtDelayExecution(false, &interval);
}

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

Да, вам нужно понимать кванты времени вашей ОС. В Windows вы даже не получите время разрешения 1 мс, если не измените квант времени на 1 мс. (Используя, например, timeBeginPeriod () / timeEndPeriod ()) Это все равно ничего не гарантирует. Даже небольшая загрузка или один дрянной драйвер устройства все скинут.

SetThreadPriority () помогает, но довольно опасно. Плохие драйверы устройств по-прежнему могут вас испортить.

Вам нужна сверхуправляемая вычислительная среда, чтобы эта уродливая штука вообще работала.

Обычно сон длится, по крайней мере, до следующего системного прерывания. Однако это зависит от настроек ресурсов мультимедийного таймера. Может быть установлено значение, близкое к 1 мс, некоторые аппаратные средства даже позволяют работать с периодами прерывания 0,9765625 (ActualResolution, предоставленный NtQueryTimerResolution, покажет 0,9766, но это на самом деле неверно. Они просто не могут поставить правильный число в формате ActualResolution. Это 0,9765625 мс при 1024 прерываниях в секунду).

Есть одно исключение, которое позволяет нам избежать того факта, что может быть невозможно спать меньше периода прерывания: это знаменитый Sleep(0). Это очень мощный инструмент, и он используется не так часто, как следовало бы! Он отказывается от напоминания о временном интервале потока. Таким образом, поток остановится до тех пор, пока планировщик не заставит поток снова получить службу процессора. Sleep(0) - асинхронная служба, вызов заставит планировщик реагировать независимо от прерывания.

Второй способ - использовать waitable object. Функция ожидания, такая как WaitForSingleObject(), может ждать события. Чтобы поток спал в течение любого времени, в том числе в микросекундном режиме, потоку необходимо настроить некоторый служебный поток, который будет генерировать событие с желаемой задержкой. «Спящий» поток настроит этот поток, а затем остановится в функции ожидания, пока служебный поток не установит событие с сигналом.

Таким образом, любой поток может «спать» или ждать в любое время. Сервисный поток может быть очень сложным и предлагать общесистемные сервисы, такие как синхронизированные события с микросекундным разрешением. Однако разрешение в микросекундах может вынудить поток службы вращаться на службе времени с высоким разрешением не более одного периода прерывания (~ 1 мс). Если проявить осторожность, он может работать очень хорошо, особенно в многопроцессорных или многоядерных системах. Вращение в одну мс не сильно повредит многоядерной системе, когда маска сродства для вызывающего и служебного потоков тщательно обрабатывается.

Код, описание и тестирование можно найти на сайте Windows Timestamp Project.

Как указали несколько человек, сон и другие связанные функции по умолчанию зависят от «системного тика». Это минимальная единица времени между задачами ОС; например, планировщик не будет работать быстрее этого. Даже в ОС реального времени системный тик обычно составляет не менее 1 мс. Хотя он настраивается, это имеет последствия для всей системы, а не только для вашей функции сна, потому что ваш планировщик будет работать чаще и потенциально увеличивать накладные расходы вашей ОС (количество времени для запуска планировщика по сравнению с количеством время выполнения задачи).

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

Если вам нужна такая степень детализации, вы находитесь не в том месте (в пространстве пользователя).

Помните, что если вы находитесь в пользовательском пространстве, ваше время не всегда точно.

Планировщик может запускать ваш поток (или приложение) и планировать его, поэтому вы зависите от планировщика ОС.

Если вы ищете что-то точное, вам нужно пойти: 1) В пространство ядра (например, драйверы) 2) Выбрать RTOS.

В любом случае, если вы ищете некоторую детализацию (но помните о проблеме с пользовательским пространством), посмотрите на функции QueryPerformanceCounter и QueryPerformanceFrequency в MSDN.

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

В противном случае вам следует подумать, есть ли событие, с которым вы можете синхронизироваться, или, в худшем случае, просто занято, дождитесь процессора и используйте API-интерфейс высокопроизводительного счетчика для измерения прошедшего времени.

Фактически использование этой функции usleep приведет к большой утечке памяти / ресурсов. (в зависимости от того, как часто звонят)

используйте эту исправленную версию (извините, не можете редактировать?)

bool usleep(unsigned long usec)
{
    struct timeval tv;
    fd_set dummy;
    SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    FD_ZERO(&dummy);
    FD_SET(s, &dummy);
    tv.tv_sec = usec / 1000000ul;
    tv.tv_usec = usec % 1000000ul;
    bool success = (0 == select(0, 0, 0, &dummy, &tv));
    closesocket(s);
    return success;
}

У меня такая же проблема, и ничто не работает быстрее, чем мс, даже Sleep (0). Моя проблема заключается в связи между клиентским и серверным приложением, где я использую функцию _InterlockedExchange для тестирования и установки бита, а затем я сплю (0).

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

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

Чтобы вы, ребята, поняли, насколько медленным является этот сон, я провел тест в течение 10 секунд, выполнив пустой цикл (получилось что-то вроде 18 000 000 циклов), тогда как при наличии события у меня было только 180 000 циклов. То есть в 100 раз медленнее!

Попробуйте использовать SetWaitableTimer. ..

Как уже упоминалось, действительно нет никаких гарантий относительно времени сна. Но никто не хочет признавать, что иногда в простаивающей системе команда usleep может быть очень точной. Особенно с бестикальным ядром. Он есть в Windows Vista, а в Linux - начиная с версии 2.6.16.

Бесконтактные ядра существуют, чтобы помочь улучшить жизнь ноутбуков: ср. Утилита Intel powertop.

В этом состоянии мне довелось измерить команду Linux usleep, которая очень точно соблюдает запрошенное время сна, вплоть до полдюжины микросекунд.

Так что, возможно, OP хочет что-то, что будет грубо работать большую часть времени в системе на холостом ходу, и иметь возможность запрашивать планирование микросекунд! На самом деле я бы тоже хотел этого в Windows.

Также Sleep (0) звучит как boost :: thread :: yield (), терминология которого более ясна.

Интересно, имеют ли блокировки с Boost более высокую точность. Потому что тогда вы можете просто заблокировать мьютекс, который никто никогда не выпускает, и, когда истечет время ожидания, продолжить ... Таймауты устанавливаются с помощью boost :: system_time + boost :: milliseconds & cie (xtime устарел).

Если ваша цель - «подождать очень короткий промежуток времени», потому что вы выполняете спин-ожидание, то уровни ожидания, которые вы можете выполнить, увеличиваются.

void SpinOnce(ref Int32 spin)
{
   /*
      SpinOnce is called each time we need to wait. 
      But the action it takes depends on how many times we've been spinning:

      1..12 spins: spin 2..4096 cycles
      12..32: call SwitchToThread (allow another thread ready to go on time core to execute)
      over 32 spins: Sleep(0) (give up the remainder of our timeslice to any other thread ready to run, also allows APC and I/O callbacks)
   */
   spin += 1;

   if (spin > 32)
      Sleep(0); //give up the remainder of our timeslice
   else if (spin > 12)
      SwitchTothread(); //allow another thread on our CPU to have the remainder of our timeslice
   else
   {
      int loops = (1 << spin); //1..12 ==> 2..4096
      while (loops > 0)
         loops -= 1;
   }
}

Поэтому, если ваша цель на самом деле подождать совсем немного, вы можете использовать что-то вроде:

int spin = 0;
while (!TryAcquireLock()) 
{ 
   SpinOne(ref spin);
}

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

Попробуйте boost :: xtime и timed_wait ()

имеет наносекундную точность.

Просто используйте Sleep (0). 0 явно меньше миллисекунды. Звучит смешно, но я серьезно. Sleep (0) сообщает Windows, что вам сейчас нечего делать, но вы действительно хотите, чтобы вас пересмотрели, как только планировщик снова запустится. И поскольку очевидно, что выполнение потока невозможно запланировать до запуска самого планировщика, это самая короткая возможная задержка.

Обратите внимание, что вы можете передать в usleep микросекундное число, но это не значит, что usleep (__ int64 t) {Sleep (t / 1000); } - нет никаких гарантий, что вы действительно спите в этот период.

Функция сна, которая длится меньше миллисекунды, может быть

Я обнаружил, что у меня работает sleep (0). В системе с почти 0% загрузкой процессора в диспетчере задач я написал простую консольную программу, и функция sleep (0) спала в течение последовательных 1-3 микросекунд, что намного меньше миллисекунды.

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

Но как я понимаю, функцию сна не стоит использовать как таймер. Его следует использовать для того, чтобы программа использовала как можно меньше ресурсов процессора и выполнялась как можно чаще. Для моих целей, таких как перемещение снаряда по экрану в видеоигре, намного быстрее, чем один пиксель в миллисекунду, я думаю, что режим сна (0) работает.

Вы просто должны убедиться, что интервал сна намного меньше, чем наибольшее время, в течение которого он будет спать. Вы не используете спящий режим в качестве таймера, а просто для того, чтобы игра использовала минимально возможный процент процессора. Вы бы использовали отдельную функцию, которая не имеет никакого отношения к сну, чтобы узнать, когда прошло определенное количество времени, а затем переместить снаряд на один пиксель по экрану, скажем, за 1/10 миллисекунды или 100 микросекунд. .

Псевдокод будет выглядеть примерно так.

while (timer1 < 100 microseconds) {
sleep(0);
}

if (timer2 >=100 microseconds) {
move projectile one pixel
}

//Rest of code in iteration here

Я знаю, что ответ может не работать для сложных задач или программ, но может работать для некоторых или многих программ.

В Windows использование select заставляет вас включать Winsock, которая должна быть инициализирована в вашем приложении следующим образом:

WORD wVersionRequested = MAKEWORD(1,0);
WSADATA wsaData;
WSAStartup(wVersionRequested, &wsaData);

И тогда выбор не позволит вам вызываться без какого-либо сокета, поэтому вам нужно сделать еще немного, чтобы создать метод микросна:

int usleep(long usec)
{
    struct timeval tv;
    fd_set dummy;
    SOCKET s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);
    FD_ZERO(&dummy);
    FD_SET(s, &dummy);
    tv.tv_sec = usec/1000000L;
    tv.tv_usec = usec%1000000L;
    return select(0, 0, 0, &dummy, &tv);
}

Все эти созданные методы usleep возвращают ноль в случае успеха и ненулевое значение в случае ошибок.