D1 garbage collector + threads + malloc = garbage?

[Walter Bright]

Sean Kelly wrote:
> Walter Bright Wrote:
> 
>> Sean Kelly wrote:
>>> Leandro Lucarella Wrote:
>>> 
>>>> Bane, el 11 de diciembre a las 06:00 me escribiste:
>>>>> Bug with GC fullCollect() in multithreaded environment.
>>>>> Grauzone explained it here 
>>>>> http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=99610
>>>>> 
>>>>> 
>>> To be perfectly safe, it's a tiny bit trickier than that.  You
>>> have to always lock on allocations instead of just locking the
>>> collection cycle in single-threaded apps.  I think the reason for
>>> this is that once the lock is acquired it must be held until the
>>> current thread exits the GC code, and the "synchronized"
>>> statement only allows you to lock for the length of the collect()
>>> call (because the start and end must be within the same scope).
>>> However, this /may/ actually be a separate bug with the D 1.0 GC.
>>> I really can't recall for sure if this was an issue with
>>> collecting when all the other threads were suspended.
>> Yes, the lock on the gc must still be held until the collection
>> work is completed, but the other threads can be unfrozen once the
>> mark phase is complete.
> 
> Hm... so if a dtor creates a new thread then that thread could enter
> and "lock" the GC while the first thread is still completing its
> allocation.  Couldn't this cause problems?

No, because the thread doing the GC collection has locked the GC. Any 
other thread attempting to alloc will wait on that lock. There is only 
one GC lock.