Подтвердить что ты не робот

Альтернативы Thread.Sleep() для имитации пауз

Так что Thread.Sleep() плохо (http://msmvps.com/blogs/peterritchie/archive/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program.aspx).

Есть ли рекомендованная альтернатива симуляции паузы при выполнении программы? Например, петля? Хотя я предполагаю, что это связано с большим количеством накладных расходов при инициализации переменных, проверкой состояния bool и т.д.

Спасибо

4b9b3361

Ответ 1

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

Ответ 2

Моделирование паузы

"Имитация" звучит как то, что вы делали бы только при отладке. Thread.Sleep должно быть хорошо.

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

Другое, на что нужно обратить внимание - вызывать Thread.Sleep из потока пользовательского интерфейса, что сделает пользовательский интерфейс невосприимчивым. Лучше отключить части пользовательского интерфейса, с которыми вы не хотите взаимодействовать, а затем использовать элемент управления Timer для реализации задержки.

Ответ 3

Из того, что вы сказали, вы пытаетесь имитировать паузу в выполнении.

Thread.Sleep отлично подходит для этого. Даже связанная с вами статья начинается с:

Thread.Sleep использует его: имитирует длительные операции при тестировании/отладке в потоке MTA.

Ответ 4

Я не согласен с оценкой, что Thread.Sleep() является "плохим". Это зависит от ситуации.

В режиме консольного режима может быть вполне уместно спать поток, если вы чего-то ждали. Возможно, даже в цикле: проверьте условие, спите немного, если оно не выполнено, повторите.

Однако в графической программе, как правило, вы не будете спать в главном (GUI) потоке. Это связано с тем, что в наши дни интерфейсы GUI разработаны с использованием одного интерактивного потока. Если вы спите в этом потоке, весь ваш графический интерфейс будет казаться "заблокированным" на время, когда вы спите. Лучшей ситуацией может быть использование какого-то таймера (у всех графических интерфейсов есть такая концепция).

Одна вещь, которую вы делаете не, - это написать цикл, который постоянно проверяет, чтобы какое-то условие было истинным, даже не спящим. Это приведет к тому, что один процессор будет работать до 100%, потому что процессор хочет выполнить свою работу как можно быстрее. Это не только неожиданно с точки зрения пользователя, но и недружелюбно, потому что такая деятельность может голодать процесс, который вы на самом деле ожидаете достаточно циклов, чтобы выполнить свою работу!

Ответ 5

Если вы ожидаете появления какого-либо кода или события, вы можете использовать команды ожидания.

Ответ 6

В то время как сама статья спорна, я согласен с его стартовым предложением, в котором рассматривается ваше беспокойство

Thread.Sleep использует: имитацию длительные операции тестирование/отладка в потоке MTA. В .NET нет других причин для использования он.

Я считаю, что то, о чем вы спрашиваете (имитируя паузы), и является основным использованием Thread.Sleep()

Ответ 7

Я считаю, что Раймонд Чен рекомендовал установить приоритет потока ниже

http://blogs.msdn.com/oldnewthing/archive/2009/07/27/9849503.aspx

Я не совсем понимаю, почему вы так часто останавливаетесь. Почему бы просто не выполнять работу с низким приоритетом? Когда есть более важные дела, ваш фоновый поток перестает делать то, что он делает. Когда есть доступный CPU, ваш фоновый поток будет делать все как можно быстрее (пока не придет что-то с более высоким приоритетом).

Ответ 9

Я хотел бы поспорить, что в большинстве случаев, когда программист думает об использовании Thread.Sleep(), некоторый простой код, который использует event, будет работать очень хорошо.