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):<br>
<br>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.<br>
<br>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.<br>
<br>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.<br>
<br><div class="gmail_quote">On Mon, Nov 1, 2010 at 12:17 PM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 11/1/10 10:59 AM, Michel Fortin wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Le 2010-11-01 à 0:21, Andrei Alexandrescu a écrit :<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Alright, then how do we solve refcounting of constant objects (see<br>
Michel Fortin's question)? My solution involves casting away const<br>
and keeping immutability information at runtime. Is that<br>
acceptable?<br>
</blockquote>
<br>
I don't see a big problem in bypassing const. But const objects might<br>
be immutable, and immutable objects are implicitly shared. So for<br>
immutable objects you'll need to use atomic increment/decrement on<br>
the reference counter; is this why you want to keep track of<br>
immutability at runtime?<br>
</blockquote>
<br></div>
I keep immutability info during runtime to avoid trying to write to immutable data.<br>
<br>
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.<br>
<br>
In brief, if we want to go with cheap copy construction, we don't currently have a solution.<br><font color="#888888">
<br>
<br>
Andrei</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</div></div></blockquote></div><br>