DMD 1.022 and 2.005 releases - what's wrong with threading?

Frits van Bommel fvbommel at REMwOVExCAPSs.nl
Sun Oct 7 00:34:08 PDT 2007


downs wrote:
> David Brown wrote:
>> This is certainly not what I would hope to ever find in a normal piece of
>> threading code.  Let's pretend I have condition variables (.NET style), and
>> see what it looks like:
>>
>>   void put(T t)
>>   {
>>     synchronized (this) {
>>       buffer ~= t;
>>       conditionSignal (this);
>>     }
>>   }
>>
>>   void get(T t)
>>   {
>>     synchronized (this) {
>>       while (buffer.length == 0)
>>         conditionWait (this);
>>       auto res=buffer[0];
>>       buffer = buffer[1..$];
>>       return res;
>>     }
>>   }
>>
> 
> Your implementation has, as far as I can tell, a fatal flaw. If
> conditionWait is called before put, put's synchronized(this) will block
> indefinitely.
> Am I missing something here?
>  --downs, confused

Yes, you seem to have missed the paragraph after the code. The 
conditionWait(this) atomically unlocks the synchronized(this) mutex and 
pauses the current thread, and then when resuming automatically relocks 
the mutex.
This means that when conditionWait is called before put, get() will no 
longer have the mutex locked when put() is called, so the 
synchronized(this) in put() won't block (assuming no other thread has 
locked that mutex in the mean time).



More information about the Digitalmars-d mailing list