On 11/1/2010 10:39 AM, Michel Fortin wrote: > Le 2010-11-01 à 12:30, David Simcha a écrit : > >> Can someone please fill me in? Despite Michael Fortin's repeated attempts >> to explain it, I still don't understand how the status quo could generate a >> race condition under reasonable, real-world scenarios. As I understand it >> (please correct whatever reasoning is wrong): >> >> 1. Incrementing/decrementing a size_t is atomic (i.e. has no intermediate >> state) on x86 and probably just about any other arch. It is not, however, >> guaranteed sequentially consistent unless you use the lock instruction. >> > >> 2. Stopping the world to do GC acts as an implicit fence. If it didn't, >> then GC would be horribly broken. This means that all refcount >> increments/decrements that happened in the owner thread should be visible to >> the collecting thread upon starting a collection. >> >> 3. You'd need some kind of fence (explicit or implicit) on terminating GC >> anyhow, to make data structures updated by the GC thread visible to all >> threads, thus making any increment/decrement of the reference count field >> done in the GC thread visible to all threads. > > > The current GC stops other threads only during mark and sweep, it then > restarts the other threads and after that it call destructors. That could be > changed, but it'd stop the world for a little longer. > > Is "i++" really atomic when i is a size_t? I though it was a > read-modify-write operation. The read might be atomic, the write might be > atomic, but the whole isn't. And in addition to atomicity, it needs to be > sequentially consistent unless we change the GC to keep threads frozen while > calling the destructors. > > One option to avoid atomic ops would be to make the GC call destructors in > the thread that owns the object, but for that you have to figure out which > thread owns what and postpone destruction until that thread allocates new > memory from the GC again. And this approach won't work for immutable objects > anyway: they're implicitly shared. >
Not relevant. In either case the memory is still referenced so won't be released. _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
