Thread.Sleep(0) : What is the normal behavior?

Question

To my understanding a Thread.Sleep(0) force a context switch on the OS.

I wanted to check what was the maximum amount of time that could pass in an application befor

Answer 1

Most likely cause is that you aren't allowing the program to read instructions in an efficient manner.

When you invoke Sleep(0) your code is suspended for a single cycle and then scheduled for the next available slot. However, this context switching isn't free - there are plenty of registers to save/load, and when you have a different sequence of instructions to read from disk you probably end up with quite a few cache misses. I can't imagine this having a significant impact on your application in most cases, but if you are working with a real-time system or something similarly intensive then it might be a possibility.

Answer 2

I was bitten by this bug in a previous project. I had a thread running which would check messages in a prioritized queue, looking for a new one. If it found no new message, I wanted the thread to go to sleep until a message's being added to the queue would wake it back up to check again.

Naively, assuming that Thread.Sleep(0) would cause the thread to go to sleep until woken up again, I found our app consuming crazy amounts of CPU once messages started coming in.

After a few days of sleuthing possible causes, we found the info from this link. The quick fix was to use Thread.Sleep(1). The link has the details around the reason for the difference, including a little test app at the bottom, demonstrating what happens to performance between the 2 options.

Answer 3

It doesn't force a context switch, only Sleep(1) does that. But if there's any other thread from any process ready to run and has a higher priority then Sleep(0) will yield the processor and let it run. You can see this by running an endless loop that calls Sleep(0), it will burn 100% CPU cycles on one core. I don't understand why you don't observe this behavior.

The best way to keep the system responsive is by giving your thread a low priority.

Answer 4

My understanding is that Thread.Sleep(0) does not force a thread context switch, it simply signals the task scheduler that you are willing to give up the rest of your time slice if there are other threads waiting to execute.

Your loop around Sleep(0) is chewing up CPU time, and that will have a negative effect on other applications (and laptop battery life!). Sleep(0) doesn't mean "let everything else execute first", so your loop will be competing for execution time with other processes.

Passing a non-zero wait time to Sleep() would be marginally better for other apps because it would actually force this thread to be put aside for a minimum amount of time. But this is still not how you implement a minimum-impact background thread.

The best way to run a CPU bound background thread with minimum impact to foreground applications is to lower your thread priority to something below normal. This will tell the scheduler to execute all normal priority threads first, and if/when there is any other time available then execute your low priority thread. The side effect of this is that sometimes your low priority thread may not get any execution time at all for relatively long periods of time (seconds) depending on how saturated the CPU is.

Answer 5

I suspect that you noticed impact due to your other program was also only CPU bound. Therefore the is also a third program running your not taking into account the OS scheduler.

The non-impacted program is getting stopped by the OS to allow your program to run, and there is context hit for swapping out the process and then loading yours then unloading it again.