Re: GC and atomic getters/setters
Re: GC and atomic getters/setters
- Subject: Re: GC and atomic getters/setters
- From: Michael Ash <email@hidden>
- Date: Sat, 17 Oct 2009 20:35:52 -0400
On Sat, Oct 17, 2009 at 1:19 PM, Michael Ash <email@hidden> wrote:
> On Sat, Oct 17, 2009 at 12:18 PM, Bill Bumgarner <email@hidden> wrote:
>>
>> On Oct 17, 2009, at 8:38 AM, BJ Homer wrote:
>>
>>> But assuming that you
>>> wanted it there in the first place, why does the GC version not need the
>>> synchronization?
>>
>> Under GC, object reference assignments -- scanned pointer assignments,
>> technically -- are, in and of themselves, atomic. Note that structures will
>> still require atomicity protection in GC, if desired (though, yes, property
>> level atomicity is generally the wrong answer for ensuring thread safety).
>>
>> In non-gc, the need to send some combination of
>> -retain/-release/-autorelease method calls leaves a window within which a
>> caller may get a hold of an object reference that is about to be released in
>> another thread. Thus, the need to use some form of locking or
>> synchronization primitive to ensure that this doesn't happen.
>>
>> As Kai said, GC's natural atomicity in object assignment is a distinct
>> advantage. In particular, it makes concurrent programming a bit less tricky
>> as there is no need to play
>> retain-on-one-thread-to-release-on-another-thread games.
>
> This discussion has me wondering about memory barriers, and I wonder
> if you or someone else knowledgeable about the GC might comment on it.
>
> As I'm sure you already know, when assigning a pointer into a shared
> memory location which is going to be read by another thread without
> synchronization, it's necessary to insert a memory barrier between the
> initialization of the memory that the pointer points to and the
> assignment itself. Likewise, on the read end, it's necessary to insert
> a memory barrier between the reading of the pointer and the reading of
> what it points to.
>
> Without the memory barrier, it's possible that the CPU could reorder
> writes so that it writes the pointer before it writes the contents,
> causing the reader to see uninitialized memory. Or, likewise, it could
> reorder reads so that it reads the contents before it reads the
> pointer, with the same consequence.
>
> It seems to me that this standard GC getter is vulnerable to this
> problem. The setter passes through a GC write barrier function which
> could very well incorporate a memory barrier. However, as far as I
> know there is no "read barrier" for GC strong pointers. It's just a
> plain old read instruction generated by the compiler, with no memory
> barrier.
>
> So it seems to me that, at least hypothetically, using the "standard"
> GC atomic getter could result in the caller seeing the object's isa
> pointer as still being 0 (or other things being uninitialized) when it
> goes to try to use it, if it happens to hit the window of opportunity
> just right, and the CPU reorders things just so. This would obviously
> have a disastrous outcome.
>
> Have I missed something? Is there some dispatch_once-style deep magic
> going on that prevents this, or something more mundane that I don't
> know about?
As was explained to me off list, the read involves a dependency (it
must know what address it's reading before it reads it) and thus it's
impossible to read them out of order without making use of a time
machine.
This just leaves the writes. I assume that the GC write barrier
includes a memory barrier, unless someone wants to tell me otherwise.
If so, then there's no problem at all.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden