Out of curiosity, why ManualResetEvent
and not AutoResetEvent
? Either way, go with the OS primitive over a sleep-check-sleep approach.
You could also use a Monitor
lock (either explicitly through Monitor.Enter
and Monitor.Exit
, or through a lock
block), but the approach should be based upon what you're actually doing; if it's a scenario of "there's only one of these things and I need exclusive access", then use a Monitor
lock. If it's "I need to wait until the other thread finishes for reasons other than resource access", then use an AutoResetEvent
or ManualResetEvent
.
The suggestions to use Thread.Join
are good if (and only if)
- You have access to the other
Thread
object
- You don't want to execute until the other thread terminates.
If either isn't true (you don't have access, or the other thread won't terminate, it will just signal an "all clear") then Thread.Join
isn't viable.
The worst option is
while(!JobCompleted);
As that will tie up the processor with needless checks of the variable without any pause in between them. Yes, it will block your thread until the operation completes, but you'll max out CPU usage (or at least a single core's worth).
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…