Каковы опасности Thread.Sleep в многопоточном коде в производственной среде

-2

Я имею дело с многопоточным кодом, написанным моим предшественником в приложении C# WinForm, которое обрабатывает большие объемы данных одновременно в производственной среде. Я определил, что в некоторых точках кода используется Thread.Sleep (20). Я не очень разбираюсь в многопоточности и имею базовые знания о примитивах потоков и синхронизации. Мне нужно знать, существуют ли какие-либо опасности, связанные с Thread.SleepКаковы опасности Thread.Sleep в многопоточном коде в производственной среде

источник

2015-05-07 3355307

Thread.sleep заставляет вашу нить спать ровно столько времени. Что делать, если ваш поток нужен только 'sleep (10)'? Вы теряете время. Есть и другие способы сделать это (я не знаю C#, вот почему это не ответ). Но в Java, например, мы «syncronized». – Shondeslitch

Парень, который написал это, вероятно, имел в виду использовать «Thread.Sleep» как средство для * not * hog a thread и дать другим потокам возможность выполнить. Он должен, однако, использовать 'Thread.Yield' – dcastro

возможный дубликат [Почему Thread.Sleep настолько вреден] (http://stackoverflow.com/questions/8815895/why-is-thread-sleep-so-harmful) – ZunTzu

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

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

источник

2015-05-07 13:41:26 Servy

Я думаю, что цель использования 'Sleep', вероятно, должна была дать поток, а не синхронизировать потоки. – dcastro

@dcastro Это возможно, хотя мне еще предстоит увидеть ситуацию, в которой это действительно подходит; в общем случае нить имеет что-то значимое, или если это не так, она должна ждать некоторого сигнала, а не фиксированного периода времени. Это показатель оживленной активности, которая почти всегда является признаком того, что что-то не так где-то (и занятая жизнь - это [бедная] форма синхронизации). – Servy

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

Каковы опасности Thread.Sleep в многопоточном коде в производственной среде

ответ

Смежные вопросы