Walter Bright Wrote: > 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.
Yeah, but it releases the lock when the collection completes, and the it retries the allocation to actually obtain memory. If the lock were held until the thread exited the GC code completely there wouldn't be a problem. I've thought about switching to using a Mutex in D2 so the lock could be acquired at the collection and released at the end of GC.malloc(), but this isn't an option in D1.
