[dmd-concurrency] Shutdown protocol

Andrei Alexandrescu andrei at erdani.com
Thu Jan 21 12:50:28 PST 2010



Steve Schveighoffer wrote:
> ----- Original Message ----
> 
>> From: Andrei Alexandrescu <andrei at erdani.com>
>>
>> Sean Kelly wrote:
>>> On Jan 21, 2010, at 12:35 PM, Steve Schveighoffer wrote:
>>>> Maybe in the event that the threads exit in the order you join them, but the 
>> end result is the main thread resumes immediately after the last thread exits.  
>> Calling join on a finished thread does not require any context switching or 
>> messages, it simply returns immediately with the exit code.
>>> Yeah exactly.  Joining in a loop shouldn't be noticeably slower than joining 
>> all in parallel.
>>
>> Not if they want to close sockets gracefully or best-effort-gracefully as in 
>> your destructor example. Actually your own destructor example ruins your point 
>> because it has a relatively high latency!!!
> 
> 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.

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


Andrei


More information about the dmd-concurrency mailing list