Thread.Sleep vs Thread.Join

Joe,

In my own experience the only difference between Thread.Join and
Thread.Sleep is how the thread actually waits.

Thread.Sleep() in theory should no stop your application from responding to
other Threads, i.e. the main one. Where as Thread.Join().

Thread.Join() will ensure that a thread has terminated, in theory, blocking
the call thread indefinatly, until the calling thread terminates.

Regards
Scott Blood
C# Developer

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...

Does anyone know the difference, in practical terms, between

Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??

The MSDN says that with Join, standard COM and SendMessage pumping
continues, but what does this mean in practice for a typical Windows
Forms or Windows Service application??

Some people say you should always use the latter.

But if you put either of these commands into simple Windows Forms app -
eg on a button event handler - the application becomes unresponsive for
10 seconds. So what's the difference (if any?)

Thanks
Joe

TMK, you only have 1 UI thread, so if you use either, your UI thread will
block (i.e. not dequeue message). Other threads that post via BeginInvoke
on the UI thread may be able to post to the queue, but the UI thread will
still be blocked. I would not ever sleep or join in the UI thread, unless
your prepard to wait and that is the required behavior (and put up the wait
cursor).

--
William Stacey [MVP]

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Does anyone know the difference, in practical terms, between
|
| Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??
|
| The MSDN says that with Join, standard COM and SendMessage pumping
| continues, but what does this mean in practice for a typical Windows
| Forms or Windows Service application??
|
| Some people say you should always use the latter.
|
| But if you put either of these commands into simple Windows Forms app -
| eg on a button event handler - the application becomes unresponsive for
| 10 seconds. So what's the difference (if any?)
|
| Thanks
| Joe
|

I've written a simple STAThread Windows Forms test app, and just as you
describe, calls made from another thread via BeginInvoke queue up until
the Sleep or Join on the main thread is over.

Nonetheless, this behavior is identical whether Thread.Sleep (x) or
Thread.CurrentThread.Join (x) is used.

So it still leaves the question, is there in fact any (non-academic)
difference between the two? Are people misled when saying Thread.Sleep
(x) is wrong and you should use Thread.CurrentThread.Join (x) instead?

Joe

On 20 Mar 2006 02:06:56 -0800, Joe wrote:

So it still leaves the question, is there in fact any (non-academic)
difference between the two? Are people misled when saying Thread.Sleep
(x) is wrong and you should use Thread.CurrentThread.Join (x) instead?

I suppose that you could have a look at how Sleep() and Join() have been
implemented in the .NET Framwork (suing Reflector) and find out by
yourslef.

I do not have the answer to your question but I have to say that in 3 years
of C# programming, this is the first time that i hear that
Thread.CurrentThread.Join(x) should be used in place of Thread.Sleep(x).
Who are those "people" you are talking about. Is that an article you've
read on the Web? I'd be curious to see it. Join() and Sleep() are 2
different methods aimed at doing 2 very different things and although you
could effectively use Join in the very particular way you've shown in order
to replicate the Sleep() behaviour, i would be suprised that it would
actually be "better" (in what way?) than just using Sleep().

Hi,

Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??
its not usually Thread.CurrentThread.Join, but rather
SomeThreadRefVariable.Join, because you want to join the other thread right,
not the current thread.
The MSDN says that with Join, standard COM and SendMessage pumping
will try to read more on this and get back to you if possible ...
Some people say you should always use the latter.
as far as I know, it really depends on what you are trying to do. Talking
about Sleep, its a static call and will just suspend a thread for the
specified time. Nothing else. Useful only when, of course, you want the
thread to halt for a known number of miliseconds. Where as Join does
something very different, (it is an instance method) it waits for the
thread, that is joined, to finish (or you could of course specify a timeout
value after which execution can resume if the joined thread is still not
finished doing its thing, but for a moment forget about the over loaded
methods of join, just talking about the concept here).

So in my opinion these 2 methods are clearly for doing different things.

again Some people say you should always use the latter.
why would you want to join a thread if you dont want to join it? That is: if
you dont care when some thread will end, its not use waiting for it.

Regards,

Abubakar..

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com... Does anyone know the difference, in practical terms, between

Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??

The MSDN says that with Join, standard COM and SendMessage pumping
continues, but what does this mean in practice for a typical Windows
Forms or Windows Service application??

Some people say you should always use the latter.

But if you put either of these commands into simple Windows Forms app -
eg on a button event handler - the application becomes unresponsive for
10 seconds. So what's the difference (if any?)

Thanks
Joe

post that code, i'm not entirely following your line of reasoning either.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...

I've written a simple STAThread Windows Forms test app, and just as you
describe, calls made from another thread via BeginInvoke queue up until
the Sleep or Join on the main thread is over.

Nonetheless, this behavior is identical whether Thread.Sleep (x) or
Thread.CurrentThread.Join (x) is used.

So it still leaves the question, is there in fact any (non-academic)
difference between the two? Are people misled when saying Thread.Sleep
(x) is wrong and you should use Thread.CurrentThread.Join (x) instead?

Joe

It could be something with Power. IIR, Sleep may not put cpu in state where
good for power. Join may. Not sure, but would love to know the answer.

--
William Stacey [MVP]

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| I've written a simple STAThread Windows Forms test app, and just as you
| describe, calls made from another thread via BeginInvoke queue up until
| the Sleep or Join on the main thread is over.
|
| Nonetheless, this behavior is identical whether Thread.Sleep (x) or
| Thread.CurrentThread.Join (x) is used.
|
| So it still leaves the question, is there in fact any (non-academic)
| difference between the two? Are people misled when saying Thread.Sleep
| (x) is wrong and you should use Thread.CurrentThread.Join (x) instead?
|
| Joe
|

"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:uI**************@tk2msftngp13.phx.gbl...

It could be something with Power. IIR, Sleep may not put cpu in state where good for power. Join may. Not sure, but would love to know the answer.

....

I doubt there is difference, though I cannot prove it directly :). However,
based on how much sleep is used (in almost every program) and observing the
fact that processor temperature goes down when processor is idle, my guess
would be it does not matter. I guess processor is halted when System Idle
Process is executing.

Btw, is it just me who see your posts with date a day ahead?

Regards,
Goran

I seem to recall have some discussion with sleep and power with someone who
seemed to know the issue on c# ng. I think sleep was an issue - but maybe I
got it backwards. I will try to google to old post. Sorry for the date. I
was doing some date logic and did not notice.

--
William Stacey [MVP]

"Goran Sliskovic" <gs******@yahoo.com> wrote in message
news:us**************@TK2MSFTNGP12.phx.gbl...
|
| "William Stacey [MVP]" <wi************@gmail.com> wrote in message
| news:uI**************@tk2msftngp13.phx.gbl...
| > It could be something with Power. IIR, Sleep may not put cpu in state
| where
| > good for power. Join may. Not sure, but would love to know the answer.
| >
| ...
|
| I doubt there is difference, though I cannot prove it directly :).
However,
| based on how much sleep is used (in almost every program) and observing
the
| fact that processor temperature goes down when processor is idle, my guess
| would be it does not matter. I guess processor is halted when System Idle
| Process is executing.
|
| Btw, is it just me who see your posts with date a day ahead?
|
| Regards,
| Goran
|
|

Ignore the sleep/power thing. Was thinking about spin locks - not sleep.
Sleep should be fine in respect to power AFAICT.

--
William Stacey [MVP]

Thread.Sleep is a blocking call, that means that the thread doesn't get
scheduled for as long as the sleep time. Join on the other hand is a pumping
call, that means that the thread keeps pumping the message queue provided
it's a UI thread or an STA thread, when called on a non UI/STA thread it's
just a blocking call.
That means that you should never call Sleep on a UI thread, if you need to
wait in a UI thread, you better use a pumping wait like Thread.Join or
Wait.One.
The same goes for an STA thread (non UI), if you happen to create COM
objects (apartment threaded) in that thread, you should pump the message
queue by calling one of the pumping calls at regular intervals (for instance
after every call into COM) and certainly after having released the COM
reference.

Willy.

"Joe" <jo*******@gmail.com> wrote in message
news:11*********************@e56g2000cwe.googlegro ups.com...
| Does anyone know the difference, in practical terms, between
|
| Thread.Sleep (10000) and Thread.CurrentThread.Join (10000)??
|
| The MSDN says that with Join, standard COM and SendMessage pumping
| continues, but what does this mean in practice for a typical Windows
| Forms or Windows Service application??
|
| Some people say you should always use the latter.
|
| But if you put either of these commands into simple Windows Forms app -
| eg on a button event handler - the application becomes unresponsive for
| 10 seconds. So what's the difference (if any?)
|
| Thanks
| Joe
|

I've played around more and found that windows timers behave
differently when blocked on a sleep vs join. In the program below,
left-clicking once pauses 5 seconds then starts adding items to the
listbox, while right-clicking pauses 5 seconds then adds 5 items to the
listbox (all with the current time). In other words, timer events queue
up while blocked on a Join, but not while blocked on Sleep.

using System;
using System.Windows.Forms;

class SleepJoinForm : Form
{
Timer tmr = new Timer ();
ListBox lb = new ListBox ();

public SleepJoinForm ()
{
tmr.Interval = 1000;
tmr.Tick += delegate { lb.Items.Add (DateTime.Now); };

lb.Dock = DockStyle.Fill;
Controls.Add (lb);
lb.MouseDown += delegate (object sender, MouseEventArgs e)
{
tmr.Start ();
if (e.Button == MouseButtons.Left)
System.Threading.Thread.Sleep (5000);
else
System.Threading.Thread.CurrentThread.Join (5000);
};
}

[STAThread]
static void Main () { Application.Run (new SleepJoinForm ()); }
}

Interestingly if you replace STAThread with MTAThread, the Join-wait
behaves just like the Sleep-wait. I think you're right in that it's
related to message pumping.

I wonder if it's possible for a similar issue to crop up in a non-UI
application? Unfortunately I'm largely ignorant of COM and message
pumping.

"Joe" <jo*******@gmail.com> wrote in message
news:11**********************@t31g2000cwb.googlegr oups.com...
| I've played around more and found that windows timers behave
| differently when blocked on a sleep vs join. In the program below,
| left-clicking once pauses 5 seconds then starts adding items to the
| listbox, while right-clicking pauses 5 seconds then adds 5 items to the
| listbox (all with the current time). In other words, timer events queue
| up while blocked on a Join, but not while blocked on Sleep.
|

There is no message pumping/dispatching while the UI thread is 'Sleeping'.
On the other end, when you call Join on the current thread you still pump
messages, that means that your Timer messages are getting dispatched when
they arrive, the only thing that's not been handled are the painting
messages, that's why the list is only repainted after the Join time-out
period.

| using System;
| using System.Windows.Forms;
|
| class SleepJoinForm : Form
| {
| Timer tmr = new Timer ();
| ListBox lb = new ListBox ();
|
| public SleepJoinForm ()
| {
| tmr.Interval = 1000;
| tmr.Tick += delegate { lb.Items.Add (DateTime.Now); };
|
| lb.Dock = DockStyle.Fill;
| Controls.Add (lb);
| lb.MouseDown += delegate (object sender, MouseEventArgs e)
| {
| tmr.Start ();
| if (e.Button == MouseButtons.Left)
| System.Threading.Thread.Sleep (5000);
| else
| System.Threading.Thread.CurrentThread.Join (5000);
| };
| }
|
| [STAThread]
| static void Main () { Application.Run (new SleepJoinForm ()); }
| }
|
| Interestingly if you replace STAThread with MTAThread, the Join-wait
| behaves just like the Sleep-wait. I think you're right in that it's
| related to message pumping.
|
| I wonder if it's possible for a similar issue to crop up in a non-UI
| application? Unfortunately I'm largely ignorant of COM and message
| pumping.
|
That's what I said in my previous response, the CLR pumps the queue only
when Join is called on a STA thread, otherwise it behaves 'like' a Sleep.
You see there are two pre-requisites, you need a thread with a message queue
that runs in a STA. All UI threads have a message queue and they should run
in a STA, a non UI thread that hosts a apartment threaded COM object, must
run in a STA AND MUST pump the message queue. The CLR performs a (limited)
pumping wait when one of the following API's; Monitor.Enter (lock in C#),
Thread.Join, WaitOne, GC.WaitForPendingFinalizers are called from a STA
thread that has a message queue (a window really) attached.
A non UI STA thread that creates an instance of COM object MUST pump the
message queue. Failing to pump, will block the finalizer thread when one
releases the reference to the COM object(s). That means that at least you
should call WaitForPendingFinalizers after you released the Object
reference.

Willy.

Thanks.
Joe