Re: GC and atomic getters/setters
Re: GC and atomic getters/setters
- Subject: Re: GC and atomic getters/setters
- From: Ken Ferry <email@hidden>
- Date: Sat, 17 Oct 2009 18:36:49 -0700
On Sat, Oct 17, 2009 at 6: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.
>
This is the kind of reasoning you want to avoid, actually. That's true on
most but not all architectures. That article does explain.
It's true on all architectures on which Cocoa is available, but even so, to
write clear code whose correctness is verifiable, you don't want to rely on
things like that.
>
> 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.
>
> --Kyle Sluder
>
_______________________________________________
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