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

В 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 возвращают ноль в случае успеха и ненулевое значение в случае ошибок.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фактически использование этой функции 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;
}

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

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

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

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

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

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

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

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

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

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

Код, описание и тестирование можно найти на Проект отметки времени Windows

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

#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);
}

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

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

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

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

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

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

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

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

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

//Rest of code in iteration here

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

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

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);
}

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