Looking for Advice on Thread.Sleep

[Cider123]

I ran into a situation where my Window Service had to process 100,000+
files, when I first noticed I needed to tweak various routines.

Everything runs fine, but here's what I ran into:

In the routine that loops through the file buffer:

for (int i=0;i < _Buffer.length; i++)
{
// Code here
}

If I run it as is, it throttles CPU usage 100%.

If I toss in a simple statement:

Thread.Sleep(1);

The CPU usage throttles around 0-3% as it works through the list.

The difference in files processed is amazingly different though,
something to the tune of 9-10,000 files without the Sleep. 800-1000
files with. (Report dumped once a minute to Event Log).

Looking through various code in this Newsgroup, I've seen
Thread.Sleep(0) instead of Thread.Sleep(1).

2 Questions I have are:

1) Why use 0 instead of 1 if you actually want the Thread to sleep?

2) Is there a better way to run a process that is I/O intensive, SQL
intensive and keep the CPU throttle within reason, other than
incorporating Thread.Sleep statements within the looping mechanisms ?

 

[Nicholas Paldino [.NET/C# MVP]]

Cider,

If you want to keep the CPU from being so overwhelmed, I would consider
using the threadpool. Basically, I would have a list of items that you need
to process. Once you have that, you place an item (or items) in the
threadpool and have them process one item at a time. When an item is done,
it would add a new item to the threadpool (if there were items in the list
to process).

If you do it this way, I assume performance is going to decline, but you
will not get the excessive CPU usage. You are going to see that generally,
by throttling the CPU usage, you will not be able to process that many items
at a time.

Hope this helps.

 

[Michael Giagnocavo [MVP]]

You could have it sleep on every X number of loops. If this is commercial
ware to be packaged and run on different hardware, then you could use
PerformanceCounters to see how much CPU you are using, and dynamically
change how often or length of the sleep.

Thread.Sleep(0) will tell the processor to let other executing threads run.
This is probably the best (if there is no work needed, your proc will get
more CPU time, but if other load is heavy, it will give it up). Depending
on the length of each iteration, you might consider doing this every X
iterations.

And, of course, if you use less CPU for the same code, you're going to get
less work done .

-mike
MVP

 

[Willy Denoyette [MVP]]

Just reduce the priority of the service to something below Normal and call
Thread.Sleep(0) to give up your thread quota at the end of the loop.

Willy.

 

[J.Marsch]

One thing that I would consider is whether you need for this thread to
yield. Is this process a background task, or is this the server's primary
responsibility? Seems weird, but sometimes if the CPU is running at 100%,
it just means that you are operating efficiently. 2000/NT is a
preemptive-multitasking operating system, so it can interrupt (preempt) your
thread if it needs to. The operating system is going to share the CPU time,
and if possible, it's going to throttle the CPU to 100%. It wants to fully
utilize the CPU -- it's trying to hit 100%. Thing is, there usually isn't
enough going on to keep the CPU that busy.

Now, if you are finding that other, competing operations are occuring too
slowly, then maybe there is some tuning to do.

Said another way, I wouldn't be too concerned about the CPU hitting 100%,
unless it is having too heavy an impact on other applications on the server.
What you probably want is for your I/O process to get as much CPU time as it
can, and yet yield time to other applications as necessary.

If your thread is running at normal priority, it will be pre-empted if a
higher priority item comes up. It will share time with threads of equal
priority, and it will preempt threads of lower priority. If you are
experiencing a performance issue with other systems on the server, then your
thread may be competing too aggressively.

You might try playing with sleep(0), you might do it only x number of
iterations. That will cause your thread to yield to other threads. Now, if
you are doing a sleep(1) (or anything >0), you are really telling your
thread to yield to any other thread that is running, even the low-priority
ones. I'm not sure whether sleep(0) yields to lower priority threads or
not).

If your process is supposed to be strictly a background process (work as
hard as you can, unless something interrupts you), then you can just alter
its priority. If it's running at a slightly lower than normal priority, it
will consume 100% CPU if it can, but if any normal priority thread (and most
threads are normal) needs attention, your process thread will be preempted
by the operating system. The most notable example of this that I can think
of would be the grid computing community ware out there -- like that cancer
genome project, or the SETI downloadable that runs in the backgound. Those
processes have almost no impact on your throughput if your computer is doing
something, but they consume 100% cpu time if your machine goes idle -- they
do that by manipulating their thread priority.

The downside to changing priority is that your process can be starved by
another thread. If a normal priority thread gets busy for several minutes
(or an hour or so), and you have reduced the priority of your I/O process
thread, then your thread will be preempted (starved) while the higher
priority threads run.

Using Sleep() + normal priority your thread would not be starved by other
normal -priority threads. On the other hand (I know, too many hands <g>),
you don't want to overdo it with the sleep commands. Every time the CPU
stops executing one thread and picks up another, it has to do what's called
a "context switch". I don't know all of the details of what goes on during
a context switch -- I think that a bunch of state data has to be saved for
the sleeping thread and loaded for the upcoming thread. I do know that they
are pretty expensive, and if you sleep your thread too often (or if you get
too many threads running), you will actually be wasting CPU time performing
context switches.

I would advise that you don't get too hung up on CPU utlization, and instead
examine the performance of the server holistically. How are the other
applications performing with this process running? Then you can tune your
process thread with sleeps or priority settings to achieve a satisfactory
throughput.

You can test that stuff that I told by by doing a little while loop:
while (true) {} and checking system responsiveness.

 

[Jerry Houston]

Another reason to be concerned about pegging the CPU is if you're writing
competitive software.

Review writers sometimes make an issue of it, and can convey to readers the
impression that your software is poorly written, because it maxes-out the
CPU resources. The implication is that your software is running at the
expense of other software on the same machine, and many users would consider
that a negative.

Sometimes it's not good enough just to write good software. It has to be
PERCEIVED to be good software. (If it's for in-house use only, then
obviously this isn't an issue at all.)

 

[J.Marsch]

Jerry:

That's a very good point. Unfortunate, but good. Yes, I can see how
pegging the CPU could be perceived as a bad thing, even though it might
really mean that everything is working just fine.

Perhaps a reasonable strategy might be to make the throttle tunable. Then,
the software could ship slightly detuned by default, so that it would not
use 100% CPU (and probably not run as fast). Then the people who have to
use the software could re-tune for performance.

Regards

Jeremy

 

[Michael Giagnocavo [MVP]]

Or have a "Are you a software reviewer?" checkbox on installation . Or
ship reviewers special copies with different setup files. Since they have
to write review after review, many times they don't really know how to
evaluate something (industry-specific reviewers are somewhat better though).

-mike
MVP

 

[J.Marsch]

You know, thinking back, I wonder if Microsoft did that with SQL Server. I
remember that with SQL Server 6.0, one of the first things that you had to
do after installing was to go in and increase the amount of memory that it
was allowed to use for caching, because it shipped with some ridiculously
low value (8MB?).