[ACCEPTED]-To make a choice between ManualResetEvent or Thread.Sleep()-manualresetevent

Out of curiosity, why ManualResetEvent and not AutoResetEvent? Either 19 way, go with the OS primitive over a sleep-check-sleep 18 approach.

You could also use a Monitor lock (either 17 explicitly through Monitor.Enter and Monitor.Exit, or through a lock block), but 16 the approach should be based upon what you're 15 actually doing; if it's a scenario of "there's 14 only one of these things and I need exclusive 13 access", then use a Monitor lock. If it's "I need 12 to wait until the other thread finishes for reasons other than resource 11 access", then use an AutoResetEvent or ManualResetEvent.

The suggestions 10 to use Thread.Join are good if (and only if)

1. You have access to the other Thread object
2. You don't want to execute until the other thread terminates.

If either 9 isn't true (you don't have access, or the 8 other thread won't terminate, it will just 7 signal an "all clear") then Thread.Join isn't viable.

The 6 worst option is

while(!JobCompleted);

As that will tie up the processor 5 with needless checks of the variable without 4 any pause in between them. Yes, it will 3 block your thread until the operation completes, but 2 you'll max out CPU usage (or at least a 1 single core's worth).

The event makes more efficient use of the 3 processors- you're not having to wake the 2 parent thread up to poll. The kernel will 1 wake you up when the event fires.

If you have access to the original Thread 4 object, or can get that access, you're best 3 off using Thread.Join().

Edit: Also, if this is taking 2 place in a GUI like WinForms or WPF, you 1 may want to consider using BackgroundWorker

The main disadvantage to using Thread.Sleep() is that 10 you are making the decision on how long 9 the thread will wait. The operation you 8 are waiting for may take more or less time, and 7 in general, it is very difficult to precisely 6 quantify that time. If the thread sleeps 5 too long, then you are not making best use 4 of system resources.

In order to be optimal, you 3 should use ManualResetEvent (or AutoResetEvent) so that your thread is 2 resumed as soon as the dependent operation 1 finishes.

ManualResetEvent is definitely the way to 8 go.

From the code snippet you supplied, it 7 looks like you are delegating the execution 6 within your Execute method. If this is 5 the case, and you are only delegating a 4 single task, why are you delegating to another 3 thread at all if you have to wait for the 2 response? You may as well just execute 1 the process synchronously.

manualresets are comparitively slower because 14 they go out of managed code and back in..

They 13 are probably slower than say a Wait/Pulse combo, which you should use here in my opinion. But Manual/AutoResetEvents will 12 be way faster than any Thread.Sleep(x) that you do, even 11 if you choose x = 1. And even if you lower the 10 Windows timer resolution to 1ms.

What if 9 I just had an empty while contruct? Whats 8 the difference...?

Then one core will spin 7 at 100% until the condition turns true, stealing 6 away time from other threads that might 5 instead use it to do something useful, like 4 calculating frames for "Angry Birds" - or 3 the cpu could simply cool off a bit, delaying 2 the dire effects of global warming for some 1 further nanoseconds.

Both approaches do the same thing basically. The 8 while loop is little bit more explicit however, since 7 you can specify the sleep time. Although 6 I would use the XXXResetEvent classes which 5 are meant to be used in the scenario your 4 working in. I would assume the threading 3 classes would be implemented now or later 2 with more robust threading code to handle 1 maybe thread affinity on multi core processors.