[dmd-concurrency] Shutdown protocol

[Robert Jacques]

On Wed, 20 Jan 2010 15:38:45 -0500, Michel Fortin  
<michel.fortin at michelf.com> wrote:
> Le 2010-01-20 à 15:12, Robert Jacques a écrit :
>
>> On Wed, 20 Jan 2010 14:24:34 -0500, Michel Fortin  
>> <michel.fortin at michelf.com> wrote:
>>> Consider this case with a Dispatcher and a Worker thread communicating  
>>> with each other like this:
>>>
>>> Request:  Clients -> Dispatcher Thread -> Worker Thread
>>> Response: Clients <- Dispatcher Thread <- Worker Thread
>>>
>>> Clients send requests to a dispatcher thread. Dispatcher decides to  
>>> which worker to give the request. Worker does its work, sends the  
>>> response to the dispatcher, which sends it back to the client. Here  
>>> the dispatcher is in an infinite loop waiting for client requests, the  
>>> worker thread is in an infinite loop waiting for requests from the  
>>> dispatcher, and both know each other. Here you have your circular  
>>> reference.
>>>
>>> Is this a logic bug? I don't think so.
>>>
>>> It's true that you don't want those two threads to shutdown by  
>>> themselves in this case, but I'm a little uneasy about this being a  
>>> "feature" of reference counting.
>>
>> Good example, but not really circular. Well, so long as the worker  
>> threads don't cache the dispatcher's tid. Assuming they don't, once the  
>> number of clients goes to zero and the number of workers doing work  
>> goes to zero, the ref count on the dispatcher goes to zero and it shuts  
>> down. Then the worker ref counts go to zero and they shutdown.
>
> But is it really a logic bug to keep a reference to the dispatcher in  
> the worker thread? What if the worker thread could break its work in a  
> few pieces it and dispatch them to other workers using the dispatcher?

Yes and no. Yes, it is perfectly logical for a worker to keep the  
dispatcher's tid for the length of the job/task. Once all the work is done  
and the result sent back, there's no reason for the worker to keep the  
dispatcher's tid. And in a multi-dispatcher model, every reason it  
shouldn't.