Вызов функции WinAPI Sleep () длится дольше, чем ожидалось

Question

ОС: Windows 7

При вызове функции WinAPI Sleep () как Sleep (1) поток фактически спит в течение 15 мс. Я делал это 100 раз в цикле, и общее время сна составляло 1500 мс вместо 100.

Это обычное поведение или я должен быть согласен с тем, что что-то не так с моей установкой MOBO, CPU, Windows?

РЕДАКТИРОВАТЬ: Если возможно, вы могли бы запустить этот код и напишите, как долго было время сна. Я позволил своему другу запустить это, и он фактически имел все это в 1 мс.

#include <iostream>
#include <ctime>
#include <Windows.h>

void test(void)
{
    std::cout << "Testing 1ms sleep." << std::endl;

    for (unsigned int i = 0; i < 10; i++)
    {
        std::clock_t startClocks = std::clock();

        Sleep(1);

        std::clock_t clocksTaken = std::clock() - startClocks;
        std::cout << "Time: " << clocksTaken << "ms." << std::endl;
    }
}

int main(void)
{
    test();

    std::cin.sync();
    std::cin.get();
    return 0;
}

EDIT2: кажется, что причина, по которой некоторые люди получают 1 мс, заключается в том, что запущена другая программа, которая устанавливает общесистемное разрешение таймера в 1 мс. По умолчанию это должно быть 15,6 мс в Windows 7.

Answer 1

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

Из документации :

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

Answer 2

Является ли это обычным поведением

Это.

Планировщик потоков Windows работает на временном интервале (точная длина зависит от различных факторов, включая версию и редакцию Windows).Фактически любая ненулевая задержка округляется до полного кванта.

Answer 3

Лучшие статьи, которые я нашел относительно времени в Windows: здесь и здесь .Полезная часть заключается в том, что после изменения разрешения мультимедийного таймера (например, timeBeginPeriod (1) для 1 мс) это также влияет на команду Sleep, поскольку влияет на планировщик в целом.Тем не менее, достижение точности в 1 мс невозможно в ОС без реального времени.

Answer 4

Поведение в порядке.Базовое оборудование, версия ОС и даже работающее программное обеспечение влияют на привычку ОС в отношении функции sleep ().

Если режим сна вызывается с dwMilliseconds, меньшим, чем период прерывания системы, вызов будетвернуться к следующему прерыванию.Таким образом, фактическая задержка зависит от времени, в которое вызывался режим ожидания (относительно периода прерывания).

Рекомендуется использовать интерфейс мультимедийного таймера для увеличения частоты прерывания до максимума, поддерживаемогоаппаратное обеспечение, когда требуется режим сна (1).

Подробный обзор функции режима сна (), функций ожидаемого таймера, разрешений таймера и настроек мультимедийного таймера можно найти в проекте отметки времени Windows

Answer 5

Это довольно нормальное поведение, так как большинство разрешений часов составляет около 10-15 мс.Поэтому, если вы вызываете его со значением, меньшим, чем разрешение часов (в вашем случае, 1), ему, вероятно, придется ждать хотя бы один такт, поэтому он спит дольше, чем вы хотите.1002 * Как правило, вы не должны использовать Sleep для вещей, требующих такой точности из-за этих проблем.

Answer 6

Вы должны проверить разрешение таймера вашей машины. Подробнее см. msdn документацию Sleep () .

Answer 7

(отладка или выпуск сборки?)

Как вы измеряете задержку? Вы используете точный метод? (QueryPerformanceCounter)

Я не думаю, что вам следует полагаться на ОС Windows для точного определения времени; это не операционная система реального времени, и будут внешние «силы», которые украдут время у вашего процесса.