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 13:19:22 -0400
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?
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