[dmd-concurrency] Shutdown protocol

[Steve Schveighoffer]

----- Original Message ----

> From: Andrei Alexandrescu <andrei at erdani.com>
> Steve Schveighoffer wrote:
> > 
> > Yeah, but joining one thread does not mean "Hey OS, only run this one thread 
> until it exits."  All the other threads can shut down in parallel (as they will 
> because they just got the shutdown message prior to the join loop).  Then once 
> your really long thread exits, the rest of the joins are relatively 
> instantaneous.  In other words, the effect of the loop waits until the thread 
> that takes the longest terminates.  It's the same effect as an OS primitive that 
> does the same, except as Michel pointed out, the scheduler may pull some tricks 
> to make it insignificantly faster.
> 
> You're right. I was arguing on the code:
> 
> broadcastShutdown();
> foreach (thread; threads) join(thread);
> 
> but somehow I had in mind:
> 
> foreach (thread; threads) {
>     notifyShutdown(thread);
>     join(thread);
> }
> 
> Apologies.

OK, no problem.  I'd rather be sure than drop the argument, which is why I continued it :)

> Nonetheless, Michel makes a good point about boosting thread priorities. How 
> about that? :o)

It might be a time saver, but probably it's insignificant (as Michel also mentions).  A thread not marked runnable doesn't run no matter how high it's priority is :)  In other words, if you call WaitForMultipleObjects on your list of threads, your thread isn't going to be marked runnable until they all exit anyway, so inverting the priority doesn't do much.  I'd be wary of altering the priorities of those waited threads above other threads.

But besides that, having the function doesn't hurt, calling joinAll(InputRange!Tid) is at least easier to write than a foreach loop, and it does provide an entry point for OSes that support a wait for multiple threads.  I'm not opposed to the function itself, I just was confused when you said it was way faster than a loop :)

-Steve