On 2010-10-06 16:19:45 -0400, Andrei Alexandrescu
<[email protected]> said:
On 10/6/10 14:09 CDT, Michel Fortin wrote:
The most problematic thing with reference-counted memory is that the GC
can call your struct's destructor from any thread which can cause
low-level races if the reference counter isn't manipulated with atomic
operations. And atomic operations slow things down, are you sure you
want to force this in BigInt?
The GC shouldn't be able to destroy things naively concurrently with
other threads. Currently all threads are frozen; I'm not sure whether a
frozen thread commits its writes, so that needs to be verified.
My current understanding (after looking at the GC's code) is that all
threads are frozen during the mark phase, while it builds a list of
objects to destroy. Then, threads are unfrozen while objects on the
list are destroyed.
And even if all threads were frozen while objects are being destroyed,
how do you know that one thread hasn't been frozen in the middle of a
read-modify-write operation with reference counter? Bad timing could
result in an invalid reference count. Again, you'd need an atomic
operation to make sure the GC doesn't stop a thread in the middle of a
read-modify-write.
Another solution would be to make the GC call destructors in the same
thread that owns the object, but that would require thread-local memory
pools.
Related is the discussion for this bug:
<http://d.puremagic.com/issues/show_bug.cgi?id=4621>
--
Michel Fortin
[email protected]
http://michelf.com/
