Каково различие между Потоком. Сон (тайм-аут) и ManualResetEvent. Ожидать (тайм-аут)?

Как уже упоминалось, разница в том, что WaitOne может вернуться до времени ожидания, если будет получен сигнал. Сон гарантированно дождется времени сна.

Thread.Sleep в вызовах рефлектора:

[MethodImpl(MethodImplOptions.InternalCall)]
private static extern void SleepInternal(int millisecondsTimeout);

ManualResetEvent.Wait в вызовах рефлектора:

private static extern int WaitOneNative(SafeWaitHandle waitHandle, uint millisecondsTimeout, bool hasThreadAffinity, bool exitContext);

Не уверен, есть ли разница между ними, но я посмотрю, смогу ли я что-нибудь найти.

Функция Sleep() уже давно не работает таким образом. Ее точность определяется периодом мультимедийного таймера, который можно изменить с помощью P/Invoking timeBeginPeriod(). К сожалению, на моей машине есть программа, которая устанавливает этот период равным одной миллисекунде, что делает сон точным до миллисекунды. Вот код, который вы можете попробовать сами:

using System;
using System.Diagnostics;
using System.Threading;
using System.Runtime.InteropServices;

class Program {
    static void Main(string[] args) {
        //timeBeginPeriod(1);
        var sw1 = Stopwatch.StartNew();
        for (int ix = 0; ix < 100; ++ix) Thread.Sleep(10);
        sw1.Stop();
        var sw2 = Stopwatch.StartNew();
        var mre = new ManualResetEvent(false);
        for (int ix = 0; ix < 100; ++ix) mre.WaitOne(10);
        sw1.Stop();
        Console.WriteLine("Sleep: {0}, Wait: {1}", sw1.ElapsedMilliseconds, sw2.ElapsedMilliseconds);
        Console.ReadLine();
        //timeEndPeriod(1);
    }
    [DllImport("winmm.dll")]
    private static extern int timeBeginPeriod(int period);
    [DllImport("winmm.dll")]
    private static extern int timeEndPeriod(int period);
}

Вывод на моей машине:

Sleep: 999, Wait: 1003

с вариативностью около 5 миллисекунд.

Для задержек и периодики я нашел Monitor.Wait хорошим выбором...

object timelock = new object();

lock (timelock) { Monitor.Wait(timelock, TimeSpan.FromMilliseconds(X.XX)); }

Это дает отличный результат....~1ms jitter или лучше, в зависимости от специфики приложения.

Как вы, возможно, уже знаете, Thread.Sleep(X) ненадежен и не может быть отменен.... Я избегаю его как чумы.

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

В одном потоке вы бы сказали:

    mre.WaitOne(10000); // ten seconds
    Console.WriteLine("Woke up!");

В другом вы бы сказали:

    mre.Set(); // this causes `WaitOne` to return in the first thread

Без вызова Set в другом потоке первый поток фактически спал бы в течение 10 секунд.

Основное различие между Thread.Sleep и ManualResetEvent.WaitOne заключается в том, что вы можете подать сигнал потоку, ожидающему ManualResetEvent, используя метод Set, что заставит поток проснуться раньше таймаута.

Если вы не подаете сигнал, то я ожидаю, что они будут вести себя очень похоже.

Из .NET Reflector я вижу, что метод ManualResetEvent.WaitOne в конечном итоге приводит к вызову внешнего метода со следующей сигнатурой:

int WaitOneNative(SafeWaitHandle waitHandle,
                  uint millisecondsTimeout,
                  bool hasThreadAffinity,
                  bool exitContext);

Тогда как Thread.Sleep вызывает этот внешний метод:

void SleepInternal(int millisecondsTimeout);

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