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

[David Simcha]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101101/0c83caef/attachment.html>