Home/ Questions/Q 7550555
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-30T10:14:32+00:00

After reading this SO question and noting the consensus about just how evil Thread.Sleep()

  • 0

After reading this SO question and noting the consensus about just how evil Thread.Sleep() in production code is, I decided to give an example of where I use it in production code and hopefully get an idea how to achieve what I’m currently using the Thread.Sleep() for in some other, better way…

Anyway, I have objects that are accessing a legacy system (IBM Terminal). Sometimes it can take even up to few seconds for a confirmation message to appear on the terminal screen or for screen navigation to finish. In my code I need to check if a certain system message appeared on the screen or if navigation finished by establishing that the terminal moved to the proper screen or that a certain system message was returned by the system. If the message is not on the screen or the screen has not changed I need to wait a few hundred miliseconds and try getting the confirmation string from the screen again and keep doing that either until the expected message is on the screen or the predefined operation timeout is reached.

The code looks something like this:

while (!SysOutput.Contains(successMsg) && 
OutputWaitCounter < WaitTime * Settings.Default.WaitTimeMultiplier)
{
    Thread.Sleep(Settings.Default.ThreadSleepTime);
    OutputWaitCounter++;
    DsGetAttributes = HostSession.GetAttributes(GetAttributes);
    SysOutput = DsGetAttributes.Tables[0].Rows[0][0].ToString();
}

Please ignore the DataSet stuff, that is something from the 3rd party API I have to use…

Finally, the question is simple, is using Thread.Sleep() in this context in production code okay or not? If not, how would you resolve this problem of having to wait a few hundred miliseconds before attempting to get the system output from an IBM terminal?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The problem with Thread.Sleep() is that it stops everything on that thread. I wouldn’t say that you should never use it in production code — it very much depends on what that code does and how it does it.

    If this is some single-threaded command-line app that makes these calls, honestly, I don’t see a big deal about it. If it significantly simplifies your code in this case without side effects, I say leave it in.

    If this is part of a larger application, say, with other threads and/or a rich UI, Sleep() can be problematic. Let’s say you want to signal this thread to stop immediately, presumably because someone is attempting to shut down the app (from another thread). Instead of having to wait for your Sleep() call to finish, you’d probably want to use something like a Semaphore to signal to your thread that it’s time to stop waiting, stop the thread, and clean up. So in that case, you might instead wait on the semaphore to release (with a timeout). If the call to waiting on the semaphore times out, you’d just proceed as normal, like you are doing now. If the semaphore actually released, in this case, you’d then clean up your threads and exit gracefully. Using Thread.Sleep() makes it so that your other threads would likely have to wait longer to exit in this case, because there would be no choice but to wait out the Sleep() call. If you have a UI and you’re Sleep()ing on your UI thread, calls to Sleep() will probably result in either a choppy or wholly unresponsive UI.

    • 0