Thread.Sleep is NOT evil
-
There is one case in which I have used it where it is actually useful to slow things down for the user. The case in point is an update to an application - sometimes the update is so small that all the user would see is a number of dialogues and progress bars flashing on the screen leaving them to wonder if the update has taken place. So I introduced a four second sleep in order to allow the user to see that something was happening. It has saved me from having to say "yes the update did take place, it was just very small" - that comfortable warm feeling is very important to the user.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Or something like this:
public class Utility
{
private static readonly object SyncLock = new object();public void WaitForTime(int milliseconds)
{
lock (SyncLock)
{
Monitor.Wait(SyncLock, milliseconds);
}
}public WakeAllThreads()
{
lock (SyncLock)
{
Monitor.PulseAll(SyncLock);
}
}
}I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Or something like this:
public class Utility
{
private static readonly object SyncLock = new object();public void WaitForTime(int milliseconds)
{
lock (SyncLock)
{
Monitor.Wait(SyncLock, milliseconds);
}
}public WakeAllThreads()
{
lock (SyncLock)
{
Monitor.PulseAll(SyncLock);
}
}
}I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierThanks Pete! Much appreciated :) I shall now use that method - it would be nice if Microsoft deprecated the sleep method so that people like me were prevented from using it.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Or something like this:
public class Utility
{
private static readonly object SyncLock = new object();public void WaitForTime(int milliseconds)
{
lock (SyncLock)
{
Monitor.Wait(SyncLock, milliseconds);
}
}public WakeAllThreads()
{
lock (SyncLock)
{
Monitor.PulseAll(SyncLock);
}
}
}I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Why is that better? Actually isn't that worse because when you call WakeAllThreads it will wait on the lock and your app will be unresponsive in all threads (including the one you're sending a wakeup call from)?
That's just a paste of some code I use to wake things up to kill all the threads (this is the scenario I talk about above). Monitor has a simple Pulse method as well to wake a single thread before the timeout expires.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
Let's not ;)
Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
I haven't read the article at all, but I'll give you another reason why it's evil. Every once in a while, you can get this little cryptic error message and you've got absolutely no clue as to what it means or why you're getting it: "The CLR has been unable to transition from COM context #x###### to COM context #x###### for 60 seconds. The thread that owns the destination context/apartment...blah blah blah" Why does this happen?? Well, you get this mesage onyl when running under the debugger. Usually it's because Thread.Sleep has been called for greater than 60 seconds or there is a long running operation going on on a thread hosting a message pump. STA COM is accomplished through message passing and if those message don't get processed ... kaboom!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Simon_Whale wrote:
What would you recommend as a better method of doing the same as
thread.sleepinside a thread?If you want to run a job which executes in every 'n' minutes, you can use
System.Threading.Timer. If you want to wait till another thread finishes execution, you can use WaitHandle. If you just want to sleep, useThread.Sleep():)Best wishes, Navaneeth
sure as i pointed out earlier timer/event subscriber - but why bother. THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2. I hereby invite you synatex lawyers/bitches to put forth your challenge to overthrow this hypothesis.
dev
-
Let's not ;)
Dave
Binging is like googling, it just feels dirtier. Please take your VB.NET out of our nice case sensitive forum. Astonish us. Be exceptional. (Pete O'Hanlon)
BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) -
Thanks Pete! Much appreciated :) I shall now use that method - it would be nice if Microsoft deprecated the sleep method so that people like me were prevented from using it.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
why the appreciation? It's more code than a simple while loop with a Sleep. why you want be thankful when there really isn't a justification for it? M$ probably deprecate Thread.Sleep either because its syntax laywer told him so or simply it isn't "cool"
dev
-
No, it's not. Do you know how times I've seen Thread.Sleep show up on the UI thread?? LOTS!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
No, it's not. Do you know how times I've seen Thread.Sleep show up on the UI thread?? LOTS!
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
That's just a paste of some code I use to wake things up to kill all the threads (this is the scenario I talk about above). Monitor has a simple Pulse method as well to wake a single thread before the timeout expires.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
why the appreciation? It's more code than a simple while loop with a Sleep. why you want be thankful when there really isn't a justification for it? M$ probably deprecate Thread.Sleep either because its syntax laywer told him so or simply it isn't "cool"
dev
devvvy wrote:
why the appreciation? It's more code than a simple while loop with a Sleep.
So, you think he has to write this out every time? Chuck it in a library and you're done - a simple
new Utility().WaitForTime(5000);
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
why the appreciation? It's more code than a simple while loop with a Sleep. why you want be thankful when there really isn't a justification for it? M$ probably deprecate Thread.Sleep either because its syntax laywer told him so or simply it isn't "cool"
dev
devvvy wrote:
why the appreciation? It's more code than a simple while loop with a Sleep. why you want be thankful when there really isn't a justification for it?
Because someone, especially as it is a person I don't personally know, went out of their way to offer me help. In my books that deserves my appreciation ;)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
sure as i pointed out earlier timer/event subscriber - but why bother. THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2. I hereby invite you synatex lawyers/bitches to put forth your challenge to overthrow this hypothesis.
dev
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
Errm. Yes, we have posted arguments against, you're just choosing to ignore them. As for the reason I show Monitor.Wait is that it is close to the behaviour you're after with your Thread.Sleep, in that it puts the ThreadState into WaitSleepJoin, but it doesn't yield the thread to the OS. This is an important point because you can wake this thread up if you need to. This is the point you seem to be missing. Thread.Sleep - there is no wake up, other than through a Thread.Abort and we've already covered how that makes things unpredicable - if you need to cancel the thread and have it tidy itself up you have to wait for it to wake up. Also, Dave has a very valid point about the behaviour in STA COM. In this scenario, again, this is a justification that Thread.Sleep should not be used. It is not the appropriate mechanism.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
still - there's nothing against SCENARIO 2, if it's not a UI thread or one with a message pump. Thread.Sleep isn't evil - it's just uncool. It's uncool because most developers tell each other it's uncool to do so.
dev
OK, it's "uncool" because most people (noobs) use it like they use PictureBox. They use it without knowing it's limitations and without knowing that there are far better alternatives to it.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
Errm. Yes, we have posted arguments against, you're just choosing to ignore them. As for the reason I show Monitor.Wait is that it is close to the behaviour you're after with your Thread.Sleep, in that it puts the ThreadState into WaitSleepJoin, but it doesn't yield the thread to the OS. This is an important point because you can wake this thread up if you need to. This is the point you seem to be missing. Thread.Sleep - there is no wake up, other than through a Thread.Abort and we've already covered how that makes things unpredicable - if you need to cancel the thread and have it tidy itself up you have to wait for it to wake up. Also, Dave has a very valid point about the behaviour in STA COM. In this scenario, again, this is a justification that Thread.Sleep should not be used. It is not the appropriate mechanism.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierPete O'Hanlon wrote:
Errm. Yes, we have posted arguments against, you're just choosing to ignore them.
I second that. He don't have the maturity to understand what people are saying. So no point in discussing further. :)
Best wishes, Navaneeth My blog
-
sure as i pointed out earlier timer/event subscriber - but why bother. THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2. I hereby invite you synatex lawyers/bitches to put forth your challenge to overthrow this hypothesis.
dev
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
As Pete already told, you are ignoring the comments that we made for Scenario2. See my answer.
Best wishes, Navaneeth My blog
-
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
Errm. Yes, we have posted arguments against, you're just choosing to ignore them. As for the reason I show Monitor.Wait is that it is close to the behaviour you're after with your Thread.Sleep, in that it puts the ThreadState into WaitSleepJoin, but it doesn't yield the thread to the OS. This is an important point because you can wake this thread up if you need to. This is the point you seem to be missing. Thread.Sleep - there is no wake up, other than through a Thread.Abort and we've already covered how that makes things unpredicable - if you need to cancel the thread and have it tidy itself up you have to wait for it to wake up. Also, Dave has a very valid point about the behaviour in STA COM. In this scenario, again, this is a justification that Thread.Sleep should not be used. It is not the appropriate mechanism.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier1. As I pointed out earlier, there's no need to know *exact* when the blocked thread wakes up again. 2. STA COM debug messages -> how's debug messages in debug mode in a thread with a message pump affect me if all i've got is a non-ui baclground thread?
dev
-
devvvy wrote:
THUS FAR there isn't ONE SINGLE argument that justify against use of Thread.Sleep against SCENARIO 2.
As Pete already told, you are ignoring the comments that we made for Scenario2. See my answer.
Best wishes, Navaneeth My blog