Thread.Sleep is a sign of a poorly designed program.

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Sat, 14 Nov 2009 13:56:21 GMT

@Richard. Right, using Thread.Sleep(1) will allow any other thread to take control of the CPU for at least a time-slice.

The question is a little misguided. The parameter to Sleep is the number of milliseconds to sleep. The fact that we're using 1 millisecond as a parameter means it's *really* difficult for any number of threads to be calling Thread.Sleep at the very same time. Then, there's the fact that only one thread at a time per processor is actually running...

Your question suggests to me that you want to dip into thread prioritization. You want to periodically do no work so other applications can do some. But, you don't know what those other applications do or whether stopping your work will benefit them at all. I wouldn't suggest writing your application to do this; there's no way to do it correctly without being the operating system. Using Thread.Sleep(1) in your threads is enough for the operating system to allow other threads to be responsive. It works remarkably well.

Are you using Thread.Sleep(1) and seeing that other applications are being starved of CPU?

re: Thread.Sleep is a sign of a poorly designed program.

Richard — Sat, 14 Nov 2009 08:51:32 GMT

We are looking for a way to relinquish CPU cycles to other applications in a milti-threaded application. If we use sleep.thread(1) in each thread then my assumption is that our other threads will take the CPU.

The question is...how can we use thread.sleep(1) on all of our threads simultaneously so that CPU cycles are open for other applications?

re: Thread.Sleep is a sign of a poorly designed program.

Jimbo — Fri, 09 Oct 2009 08:30:22 GMT

How would you handle email throttling in a windows service?

Thanks.

re: Thread.Sleep is a sign of a poorly designed program.

Josh — Wed, 05 Aug 2009 03:28:11 GMT

Wow, this is a really hot topic. I must admit to not fully understanding all the intricacies of STA and MTA threads, but the discussion itself is quite enthralling. Thanks for taking the time to explain it in such detail. Now just to wrap it around my brain, lol.

re: Thread.Sleep is a sign of a poorly designed program.

Dave — Thu, 09 Jul 2009 18:09:00 GMT

I wrote a version of CPUUsage to acquire the CPU% using a timer. Is this what you mean by a good example of “Sleepless” coding?

Public Class Form1

Dim CPU_Percentage As New CPUUsage

Private Sub Timer1_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Timer1.Tick

TextBox1.Text = CPU_Percentage.GetCurrentCPUActivity & "%"

End Sub

End Class

Public Class CPUUsage

Private ReadOnly PCPUUsage As PerformanceCounter

Public Sub New()

PCPUUsage = New PerformanceCounter

PCPUUsage.CategoryName = "Processor"

PCPUUsage.CounterName = "% Processor Time"

PCPUUsage.InstanceName = "_Total"

PCPUUsage.NextValue()

End Sub

Public Function GetCurrentCPUActivity() As Integer

Return PCPUUsage.NextValue()

End Function

End Class

re: Thread.Sleep is a sign of a poorly designed program.

MikeB — Thu, 09 Jul 2009 15:24:54 GMT

Just as a foolowup -

Many of my tasks don't have to do anything for roughly 5 seconds. I use tickcount to measure that time in ms. But I don't need to be looking at that tick count every cycle. If the task works in 4.95 seconds as opposed to 5.001, I really don't care. If it takes slightly longer, I really don't care either. So, if I sleep for 100 ms before looking st tick counts, I have one line of code for someone else to follow that gets my CPU usage back down to normal.

Obviously, I could put a bunch of code in there to basically accomplish the same thing to make thread behave in a way YOU seem to need - not me.

So, my point is, you've painted with a pretty broad brush here and I just don't think your argument holds water in every case. I beleive that the sleep command DOES have a place in non-critical timing threads. Part of my job is not just getting systems to work, it's also making it easy for someone else to take over the code.

I've been writing realtime systems for a lot of years, and not once - ever - has the sleep command come back to bite me. Sometimes we don't need a sledgehammer when a tack hammer will do. It's not poor design - it's simplicity.

re: Thread.Sleep is a sign of a poorly designed program.

MikeB — Thu, 09 Jul 2009 15:10:00 GMT

I know I'm not as smart as the author or the posters here, but I use Thread.Sleep all the time.

I write software for realtime systems. I'm continually polling I/O and running state machines. If I do NOT use the sleep command when polling (and this goes for all the threads in the application - could be anywhere from 2 to 15), CPU usage goes up over 90%. If I sleep for 100 ms, it goes back close to zero.

I usually have other applications running on the system as well and I don't want to hang them up. What other method exists to run realtime loops without penalizing other applications on the same machine?

re: Thread.Sleep is a sign of a poorly designed program.

Dave — Wed, 08 Jul 2009 20:37:28 GMT

I wrote my post not in order to get information on the Sleep method but in the hopes to find a solution to the high CPU% that would allow me to eliminate the Sleep. I searched to find out how to acquire the CPU%, much like is shown in Task Manager, and came across the following MSDN page:

msdn.microsoft.com/.../system.diagnostics.performancecounter.aspx

What are your thoughts on examples on the page which use the Sleep method, especially the CPUUsage class in the community comment section?

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Wed, 08 Jul 2009 19:57:36 GMT

@Andy. I think it's a bad design because you're committing your thread for a specific amount of time, it can't be interrupted and you can't safely stop it until it stops sleeping.

re: Thread.Sleep is a sign of a poorly designed program.

Andy — Tue, 07 Jul 2009 05:14:46 GMT

I use thread-sleep to slow-down my CPU/IO intensive non-critical background tasks apps (on a server) to make it more resource friendly.

IS that a bad design?

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Tue, 30 Jun 2009 22:05:48 GMT

@Dave: The reason you see a difference between Sleep(1) and Sleep(5) (or anything below Sleep(100) is that the amount of time you give to Sleep is a recommendation, the system causes that thread to relinquish control of the the processor for a number of timeslices that fit within the requested delay time. Time slices are 100-200 ms (depending on the version of Windows) and therefore anything above 1 would effectively be 100/200.

1 and 0 have special meaning. 0 means relinquish control only if another thread of equal priority (not equal and greater) is waiting and 1 means only relinquish control if any other thread that is waiting. Sleep(0) is not recommended because it doesn't do what you expect--you should always use Sleep(1) to relinquish control to other threads.

Sleep(1) is a generally acceptable means of relinquishing control to other threads; but it's generally better to design it so it doesn't hog the CPU.

In your case, if and I were fixing it, I would move towards using a scheduling system where there is no "waiting" required--i.e. the scheduler (like Quartz.NET) is responsible for queueing up the reports to run). But, it's hard to recommend something specific without more thorough knowledge of the solution.

I really need another post that details Sleep(0) and Sleep(1)...

re: Thread.Sleep is a sign of a poorly designed program.

Dave — Tue, 30 Jun 2009 20:58:09 GMT

Back in 2003 we ported a massive Windows application to ASP.NET. The application has 200 Crystal reports with user selectable parameters (facilities, areas, items, date range, etc…) so that each report may take up to several minutes to run depending on the report, the data, and the parameters selected. Each customer has their own copy of the database. We store Session State in SQL Server, which includes the datasets for the reports. As we migrated more customers to the web app we ran into a problem in late 2007 where SQL Server would cause the CPU to hit 100% and the application would become unresponsive. As a quick workaround solution we added a Sleep(1) to our library function that executes each query. Some reports execute a few queries while others may execute thousands. This temporarily solved the problem but of course had the negative side affect of slowing the reports down. As we continued to add customers to the site we had to eventually bump up to Sleep(5) over the course of two months. We spent weeks performance tuning a number of slow running reports and have not had any problems for the past year even though we now have thousands of users. We tried lowering the Sleep last summer but the 100% CPU problem came back again. What would you suggest I do to eliminate the sleep so that the reports run faster but without SQL Server maxing out the CPU?

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Tue, 30 Jun 2009 16:54:30 GMT

@bo. The fact that it functions better with a call to Sleep(0) means it wasn't designed properly. Sleep(0) (while not as flawed as Sleep(x)) is like goto...

re: Thread.Sleep is a sign of a poorly designed program.

Bo — Tue, 30 Jun 2009 16:16:05 GMT

Back in the day when i played Everquest, that particular game had poor coding and it was very unresponsive especially if you were playing multiple accounts on the same computer and wanted to Alt-Tab between the different game instances..

As an example when you had one of your characters auto-following the other character, the character whose gameprocess did not have window focus, would fall behind because it didnt get enough time-slices to actually do all the processing it needed to do to (literally) keep up when you were running around with your characters.

Fortunatly it was possible by code injection to hook into the process and a simple Sleep(0) injected into the end of the game loop of each process made a huge difference in playability.

Suddenly it was possible to play multiple characters on the same computer, because now the available CPU ressources got distributed equally and in a fair manner between all game instances.

I'm not even sure who I blame the need for this hack on, the Everquest programmers, or the guys who wrote the windows scheduler..

I'm actually tending towards the latter.

But at least this is one case where Sleep(0) actually made a huge difference(the difference between being able to control 4 characters on one computer as opposed to max 2)

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Fri, 26 Jun 2009 17:42:44 GMT

@Niki: Using Thread.Sleep(1) will relinquish the CPU to another waiting thread; which is an acceptable use of Sleep. What happens with Sleep(10) is that it's lower than the thread quantum (which is 100-200 ms, depending on the type of the OS), which really ends up being Sleep(1).

re: Thread.Sleep is a sign of a poorly designed program.

SanjayU — Fri, 26 Jun 2009 16:38:12 GMT

I'll admit I've used it, but it does make me feel a little dirty.

re: Thread.Sleep is a sign of a poorly designed program.

Niki — Fri, 26 Jun 2009 11:20:18 GMT

I commonly use Thread.Sleep for tasks like this: I call (e.g.) Socket.Connect, but it fails because the Server is not running yet, so I have to retry connecting until the server is up. If I retry connecting right away, my connect thread will under certain conditions use 100% CPU. To prevent this, I simply call Thread.Sleep(10) after each failed attempt to connect to the server.

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Thu, 25 Jun 2009 13:23:29 GMT

@deman: If you use System.Timers or Threading.Timers, those end up being native too. It doesn't defeat the purpose, it only gets into permission issues with assemblies that call native APIs (the .NET Framework assemblies have native permissions by default).

The timers are meant as timers; it's highly unlikely that a "timer" would need to run pass 49 days, which is why it doesn't support an infinite amount of time.

Beyond 49 days (well, beyond a day; but that's beside the point) you're really looking at scheduling actions to run, not a timer. There's libraries like Quartz.NET (quartznet.sourceforge.net) for scheduling tasks.

So, the only other option with a timer is to chain timers. Set a timer for the maximum value (49+days, depending on the timer, and when that expires/elapses, start another timer--keep doing that until the final amount of time has elapsed.

re: Thread.Sleep is a sign of a poorly designed program.

deman — Thu, 25 Jun 2009 02:32:26 GMT

I can't use anything native it would defeat the purpose of my project. Bad enough that native limitations present themselves so crudely in .NET...

Every timer that uses current time as a basis is susceptible to user or automated date-time updates messing up any timing. Unless the OS updates waitable timers on every adjustment... DOES IT?

It's clear that some kind of nonadjustable counter is needed for such timings like the hardware performance counter or worst case the TickCount which is interrupt driven.

SetTimer() could have been written to work properly since there is an USER_TIMER_MAXIMUM with the value of 0x7fffffff given this one could actually handle a wraparound, I could even write the C code for it, but DID THEY?

As far as I can see from posts and writings on the net there are reliability problems with every one currently available timer. Which is insane given that it's a very very basic and common task.

re: Thread.Sleep is a sign of a poorly designed program.

PeterRitchie — Thu, 25 Jun 2009 00:22:36 GMT

@deman: I would use the native waitable timers if you want to support an interval greater than 49 days. The waitable timers support dates (UTC) so you effectively can have years between intervals. Start with www.pinvoke.net/.../SetWaitableTimer.html