Sleep - что внутри?

[eoln]

Если определять по системным часам, то Sleep(1) выполнится быстрее одного тика часов (насколько быстрее не совсем ясно), а Sleep(50) может выполниться менее чем за 50 мс, если сон начался прямо перед тиком часов; или же может выполняться чуть дольше, если уйдёт в сон сразу после тика. При ста итерациях можно предположить что 50 раз Sleep выполнялся чуть медленнее и 50 раз чуть быстрее, в среднем всё нормально, отсюда и высокая точность.

[Человек_Борща]

Да задавали уже этот вопрос, вот он. "Читаем, просвещаемся..." (с)

[7in]

Сообщение от Пепел Феникса

активное ожидание всегда грузит.

Критсекция все же для защиты ресурса, а не для ожидания.

Так, поэтому я и хочу разбавить чем-то разгружающим. Только не на 15 мс и не Sleep'ом (не нравится он мне), а на более короткий срок.

Крит.секция - для защиты ресурса, но чтобы войти в неё, иногда нужно подождать. А иногда долго (правда, ИМХО, некорректно делать такие длинные секции, но всё же можно).

[7in]

К сожалению, pause не разгружает проц вообще никак

[Пепел Феникса]

ну так и ждите нормальной критсекцией или в ядре ивентом, не надо опрашивать постоянно.

[Pavia]

Только не на 15 мс и не Sleep'ом (не нравится он мне), а на более короткий срок.

Sleep это стандартный метод. Да другого видимо нет. Если только вы сделаете или найдёте системные событие с большей частотой.

Переключение контекстов занимает порядка 1-10 мкс.
Так что мьютекс стоит делать на спинлоке длиною в 1 000 кругов. Далее Sleep(0) или если sleep не нравиться, то SwitchToThread; - тоже в цикле 1 000 раз. А далее уже имеет смысл разгружать процессор через Sleep(1).

Что касается времени срабатывания Sleep то оно зависит от загруженности процессора. И может достаточно сильно плавать.

[7in]

Сообщение от Пепел Феникса

ну так и ждите нормальной критсекцией или в ядре ивентом, не надо опрашивать постоянно.

Pavia, я так понимаю, SwitchToThread делает то же самое, что и Sleep(0), правильно?
Только вопрос: почему 1 раз на 1000 циклов Sleep(0), а не Sleep(1). И когда тогда делать Sleep(1) ?
Sleep(1) , по идее, должен SwitchToThread вызвать тоже...

[Пепел Феникса]

Sleep - всегда прерывает исполнение(оно будет возвращено по истечению таймаута)
SwitchToThread - прерывает исполнение только если нужно.

[Pavia]

SwitchToThread делает то же самое, что и Sleep(0), правильно?

По результату замеров да.

Только вопрос: почему 1 раз на 1000 циклов Sleep(0), а не Sleep(1). И когда тогда делать Sleep(1) ?

Думаю что это будет оптимальнее, хотя и не всегда. С начало 1000 раз Sleep(0), а потом уже Sleep(1).
Sleep(0)- нужен для микросекунд. Вернее мы сможем выиграть в производительности на микросекундном диапазоне. Процессор это не разгрузит, а вот производительности добавит. А вот Sleep(1) уже разгрузит процессор.

За счёт чего выигрыш?
Принудительно смена потоков происходит раз 10-250 мс. В некоторых случаях 1 мс.
Первый поток ждет пока второй поток завершит работу, а второй поток не работает так как квант времени занят первым. Поэтому мы должны сами спровоцировать переключения контекстов иначе так мы будем ждать минимум 10 мс! До принудительного переключения. Что очень долго.

Почему ОС не перераспределяет по ядрам потоки? Из-за энергосбережения она делает это редко. ОС в среднем перераспределяет процессы по ядрам если какой либо работает(висит) дольше 125 или 250 мс (не помню точно вроде второе число).

Я создал 10 потоков и у каждого в цикле написал Sleep(0) потом поменял на SwitchToThread. Результат аналогичен Process Explorer показал 5 милионов переключений на 8 поточном процессоре. 1,6 мкс на переключение.
А если сделать sleep(1) то от 300 до 1000 раз. Как видите разница на 3 порядка!

[7in]

Pavia, так оно и понятно, что будет на 3 порядка меньше. Ведь Sleep(1) делает ещё и задержку.

Тогда, наверное, стоит сделать так: X (скажем, 256) полноценных циклов с pause, затем SwitchToThread. Всё это повторяем Y раз (скажем, 4), затем заменяем SwitchToThread на Sleep(1). И всё заново.
Получается один Sleep(1) на 1024 циклов, но до него ещё 3 SwitchToThread.

Я потестил этот механизм. И на i5 2500K, и на нетбуке со слабым процем (Atom) такой код с 256 потоками грузит проц меньше, чем на 1% (примерно такая же история с 1024 потоками при кол-ве циклов до Sleep(1) 32*4=256).
p.s. Слишком частый вызов SwitchToThread тоже добавляет загрузки процу. Например 32*32 будет уже грузит i5 на 40-50% (256 потоков).

upd:
( ( 265 spin-циклов, затем SwitchToThread ) * 4 раза, затем Sleep(1) ) * 4 раза.
Итого выходит 4096 циклов. Не так много, но и не мало.
После этого переходим на Sleep(1) после каждой проверки, максимально разгружая таким образом проц.
Подобрать только более оптимально цифры надо: 256, 4, 4...