The trick is that finalizers are executed after the app threads are restarted, because running them beforehand can result in a deadlock.
On Nov 1, 2010, at 9:30 AM, David Simcha wrote: > 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. > > On Mon, Nov 1, 2010 at 12:17 PM, Andrei Alexandrescu <[email protected]> > wrote: > On 11/1/10 10:59 AM, Michel Fortin wrote: > Le 2010-11-01 à 0:21, Andrei Alexandrescu a écrit : > > Alright, then how do we solve refcounting of constant objects (see > Michel Fortin's question)? My solution involves casting away const > and keeping immutability information at runtime. Is that > acceptable? > > I don't see a big problem in bypassing const. But const objects might > be immutable, and immutable objects are implicitly shared. So for > immutable objects you'll need to use atomic increment/decrement on > the reference counter; is this why you want to keep track of > immutability at runtime? > > I keep immutability info during runtime to avoid trying to write to immutable > data. > > I'm not sure about what to do for the GC affecting the reference count. It > does look like we need to use atomic refcounting, which is a major setback > for the entire approach. > > In brief, if we want to go with cheap copy construction, we don't currently > have a solution. > > > Andrei > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos > > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
