[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[Sean Kelly]

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 <andrei at erdani.com> 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
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos