-2

I am dealing with Multi-Threaded code written by my predecessor within C# WinForm application that handles large volumes of data concurrently in production environment. I have identified that at some points within the code Thread.Sleep(20) is used. I am not very expert in multithreading and have basic knowledge of threading and synchronisation primitives. I need to know whether there are any dangers associated with Thread.Sleep

3355307
  • 1,508
  • 4
  • 17
  • 42
  • Thread.sleep make your thread sleep for a exactly amount of time. What if your thread onlye need `sleep(10)`? You are wasting the time. There are other ways to do that (I don't know C#, this is why this is not an answer). But in Java for example, we have `syncronized`. – Shondeslitch May 07 '15 at 13:41
  • The guy who wrote that probably meant to use `Thread.Sleep` as a means to *not* hog a thread, and give other threads a chance to execute. He should, however, have used `Thread.Yield` – dcastro May 07 '15 at 13:46
  • possible duplicate of [Why is Thread.Sleep so harmful](http://stackoverflow.com/questions/8815895/why-is-thread-sleep-so-harmful) – ZunTzu May 07 '15 at 13:54

1 Answers1

2

It's not going to be explicitly or directly dangerous. It's almost certainly wasting effort, as explicitly forcing your program to not do work when it has work to do is almost never sensible.

It's also a pretty significant red flag that there's a race condition in the code and, rather than actually figure out what it is or how to fix it, the programmer simply added in Sleep calls until he stopped seeing it. If true, it would mean that the program is still unstable and could potentially break at any time if enough other variables change, and that the issue should be actually fixed using proper synchronization techniques.

Servy
  • 202,030
  • 26
  • 332
  • 449
  • I think the purpose of using `Sleep` was probably to yield the thread, not synchronize threads. – dcastro May 07 '15 at 13:47
  • @dcastro That is possible, although I've yet to see a situation in which that's really appropriate myself; generally the thread either has something meaningful to do, or if it doesn't, it should be waiting for some signal, rather than a fixed period of time. It's an indication of a busywait, which is almost always a sign that something is wrong somewhere (and a busywait is a [poor] form of synchronization). – Servy May 07 '15 at 13:50
  • Sleep() does not force you program to not do work. It is a request fron the calling thread to suspend its execution for a time interval. Other threads in the program, (and threads in other processes), can continue to make forward progress. If, for example in some complex process control thread it is necessary in some circumstances to wait for at least five seconds, then Sleep(5000) is a perfectly reasonable solution. It's simple, requires no extra timer or thread/pool and will work anywhere on the caller stack without rewriting the code as a state-machine. – Martin James May 07 '15 at 14:38
  • @MartinJames It forces the thread to not do work, rather than the entire application, yes. It does cause the program to be less efficient though, as it's resulting in additional context switches. That said, the question is asking what dangers it can cause, these are the types of dangers that it can caused if used appropriately; if one doesn't care that the program is less efficient than it could be if re-written, then that's fine; they're knowingly accepting the risks. – Servy May 07 '15 at 14:51
  • If the requirement states that 'under these circumstances, the thread must not proceed for 5 seconds', there is no work for the thread to do - it is explict that is must not do any, so sleep(). Almost anything can be misused - you might as well state that loops must never be used in case they don't terminate. – Martin James May 08 '15 at 11:25
  • 1
    @MartinJames The question specifically asked, "what are the dangers of using X", so I've explained some of the dangers in using that thing. He now has the knowledge of what he needs to be looking out for in the use of this operation. – Servy May 08 '15 at 13:48