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: Sun, 18 Oct 2009 02:05:27 -0400
On Sat, Oct 17, 2009 at 9:32 PM, Kyle Sluder <email@hidden> wrote:
> On Sat, Oct 17, 2009 at 6:20 PM, Ken Ferry <email@hidden> wrote:
>> The issue concerns the order of in which changes to memory are observable by
>> other processors.
>
> Okay, and the read example is immune because you have to read the
> address before you can read the thing at that address, and it's
> therefore impossible to wind up in a bad situation due to read
> reordering, simply because the reads have to be structured in a
> particular way.
>
> I'm struggling to picture being able to write code that is sensitive
> to write reordering under GC that is not either sensitive to write
> reordering on non-GC with equivalent locking and is also not sensitive
> to other concurrency problems.
>
> Of course, I attribute this more to my lack of imagination or
> experience at the lower levels than to the lack of a good example.
With correctly done locking, your code will never see read or write
reordering, so it's no surprise that you can't picture such a
scenario. "Correctly done locking" means that all shared data is
protected by a lock, both when reading and writing.
The reason this always saves you is simply because locks incorporate
memory barriers, and thus force the correct ordering. Your code can
still experience reordering while it's within a critical section, but
no other CPU can be accessing that shared data at the same time, so it
has no ill effect. Your code can still experience reordering outside
of a critical section, but no other CPU can be accessing that data at
all, because it's not shared. The CPU can't order reads/writes into or
out of critical sections, because of the memory barriers in the locks.
There's nothing GC-specific here, except for the fact that GC lets you
write lockless accessor methods where in a non-GC land you *must*
involve a lock on both ends. (Or write some extraordinarily
complicated lockless code, which is really beyond the scope of this
thread.) I was worried because Apple's guide says that GC doesn't
require locks for this, because the locks are there to solve memory
management. They're there for more than that, but it looks like the
lockless GC approach takes care of the rest too.
In short: you only have to start worrying about weird stuff like
read/write reordering and memory barriers when you start trying to
manipulate shared data without using locks.
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