可接受使用Thread.Sleep（）

Question

I'm working on a console application which will be scheduled and run at set intervals, say every 30 minutes. Its only purpose is to query a Web Service to update a batch of database rows.

The Web Service API reccommends calling once every 30 seconds, and timeout after a set interval. The following pseudocode is given as an example:

listId := updateList(<list of terms>)
LOOP
  WHILE NOT isUpdatingComplete(listId)
END LOOP
statuses := getStatuses(“LIST_ID = {listId}”)

I have coded this roughly in C# as:

int callCount = 0;
while( callCount < 5 && !client.isUpdateComplete(listId, out messages) )
{
    listId = client.updateList(options, terms, out messages);
    callCount++;
    Thread.Sleep(30000);
}
// Get resulting status...

Is it OK in this situation to use Thread.Sleep()? I'm aware it is not generally good practice but from reading reasons not to use it this seems like acceptable usage.

Thanks.

Answer 1

Thread.Sleep ensures the current thread doesn't return until at least the specified milliseconds have passed. There are plenty of places it's appropriate to do that, and your example seems fine, assuming it's running on a background thread.

Some example places you don't want to use it - on the UI thread or where you need to do exact timing.

Answer 2

Generally speaking, Thread.Sleep is like any other tool: perfectly OK to use, except when it's terribly misused. I disagree with the "not generally good practice" part, which is the result of people abusing Thread.Sleep when they should be doing something else (ie blocking on a synchronization object).

In your case the program is single-threaded, it has no UI (ie the thread has no message loop) and you do not want to synchronize with external events. Therefore Thread.Sleep is just fine.

Answer 3

The general objection against Sleep() is that it wastes a Thread.

In your case there is only 1 Thread (maybe 2) so that is not really a problem.

So I think it looks fine (but I would sleep 29 seconds to cut some slack).

Answer 4

It's fine, except that you cannot interrupt it once it goes into sleep, without aborting the thread (which is not recommended).

That's why a ManualResetEvent might be a better idea, since it can be signalled ("awaken") from a different thread.

Answer 5

you could stick with the Thread.Sleep method. But it would be more elegant to schedule it to run every 30 minutes - so you don't have to take care of the waiting inside your application.

Answer 6

Thread.Sleep isn't the best for executing periodic logic. Thread.Sleep(n) means your thread will relinquish control for n milliseconds. There is no guarantee that it will regain control after n milliseconds, it depends on the CPU load.

Answer 7

If you are locking the thread for 30 mins case you should schedule a windows task every 30 mins, so the program executes and then ends. That way you are not locking a thread for so long.

For shorter times, like 30 secs / 1 min, System.Thread.Sleep() is perfectly fine. For more than 5 mins i would use a windows task. (Im spanish i think on the english version are called like that, im talking about the tasks you schedule from the control panel ;-) )