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