Сделать выбор между ManualResetEvent или Потоком. Сон ()
Как Вы уже предположили, NTP является решением для промышленного стандарта этой проблемы, но или интернет-соединению требуются или слою 0 источников (точные аппаратные часы, как GPS-приемник с компьютерным интерфейсом).
при использовании интернет-соединения рассмотрите использование Пул NTP .
6 ответов
Из любопытства, почему ManualResetEvent , а не AutoResetEvent ? В любом случае, используйте примитив ОС вместо подхода «спящий режим - спящий режим».
Вы также можете использовать блокировку Monitor (либо явно через Monitor.Enter и ] Monitor.Exit или через блок lock ), но подход должен быть основан на том, что вы действительно делаете; если это сценарий «есть только одна из этих вещей и мне нужен монопольный доступ», тогда используйте блокировку Monitor . Если это «мне нужно подождать, пока другой поток завершит по причинам, отличным от доступа к ресурсам», то используйте AutoResetEvent или ManualResetEvent .
Рекомендации по использованию Thread.Join хороши, если (и только если)
- у вас есть доступ к другому объекту
Thread - Вы не хотите выполняется до тех пор, пока другой поток не завершится .
Если одно из них не соответствует истине (у вас нет доступа, или другой поток не завершится, он просто выдаст сигнал «все очищено»), тогда Thread.Join не является жизнеспособным.
Наихудший вариант -
while (! JobCompleted);
Поскольку это будет связывать процессор ненужными проверками переменной без какой-либо паузы в между ними. Да, он будет блокировать ваш поток до тех пор, пока операция не завершится, но вы максимально загрузите процессор (или, по крайней мере, одно ядро).
Соединение хорошо, если (и только если)- у вас есть доступ к другому объекту
Thread - Вы не хотите выполнять, пока другой поток не завершится .
Если одно из них неверно (у вас нет доступа или другой поток не завершится, он просто выдаст сигнал «все очищено»), тогда Thread.Join не будет жизнеспособен.
Худший вариант -
while (! JobCompleted);
Поскольку это будет связывать процессор ненужными проверками переменной без какой-либо паузы между ними. Да, он заблокирует ваш поток до тех пор, пока операция не завершится, но вы максимально загрузите процессор (или, по крайней мере, одно ядро).
Соединение хорошо, если (и только если)- у вас есть доступ к другому объекту
Thread - Вы не хотите выполнять, пока другой поток не завершится .
Если одно из них неверно (у вас нет доступа или другой поток не завершится, он просто выдаст сигнал «все очищено»), тогда Thread.Join не будет жизнеспособен.
Худший вариант -
while (! JobCompleted);
Поскольку это будет связывать процессор ненужными проверками переменной без какой-либо паузы между ними. Да, он будет блокировать ваш поток до тех пор, пока операция не завершится, но вы максимально загрузите процессор (или, по крайней мере, одно ядро).
t terminate, он просто сигнализирует "все очищено") тогда Thread.Join не является жизнеспособным.
Худший вариант -
while (! JobCompleted);
Как это будет связывать процессор ненужными проверками переменной без пауз между ними. Да, он будет блокировать ваш поток до тех пор, пока операция не завершится, но вы максимально загрузите процессор (или, по крайней мере, одно ядро).
t terminate, он просто сигнализирует "все очищено") тогда Thread.Join не является жизнеспособным.
Худший вариант -
while (! JobCompleted);
Как это будет связывать процессор ненужными проверками переменной без пауз между ними. Да, он будет блокировать ваш поток до тех пор, пока операция не завершится, но вы максимально загрузите процессор (или, по крайней мере, одно ядро).
The event makes more efficient use of the processors- you're not having to wake the parent thread up to poll. The kernel will wake you up when the event fires.
If you have access to the original Thread object, or can get that access, you're best off using Thread.Join().
Edit: Also, if this is taking place in a GUI like WinForms or WPF, you may want to consider using BackgroundWorker
Главный недостаток использования Thread.Sleep () заключается в том, что вы принимаете решение о том, как долго поток будет ждать. Операция, которую вы ждете, может занять больше или меньше времени, и, как правило, очень трудно точно определить это время. Если поток находится в спящем режиме слишком долго, это означает, что вы не оптимально используете системные ресурсы.
Для достижения оптимального результата вы должны использовать ManualResetEvent (или AutoResetEvent ), чтобы ваш поток возобновляется, как только зависимая операция завершается.
ManualResetEvent - определенно правильный путь.
Судя по предоставленному вами фрагменту кода, похоже, что вы делегируете выполнение в рамках вашего метода Execute. Если это так, и вы делегируете только одну задачу, почему вы вообще делегируете другому потоку, если вам нужно дождаться ответа? Вы также можете просто выполнить процесс синхронно.
Оба подхода в основном делают одно и то же. Однако цикл while немного более явный, поскольку вы можете указать время сна. Хотя я бы использовал классы XXXResetEvent, которые предназначены для использования в сценарии, в котором вы работаете. Я предполагаю, что классы потоковой передачи будут реализованы сейчас или позже с более надежным кодом потоковой передачи для обработки, возможно, привязки потоков на многоядерных процессорах.