On Sat, Oct 17, 2009 at 9:32 PM, Kyle Sluder <kyle.slu...@gmail.com> wrote: > On Sat, Oct 17, 2009 at 6:20 PM, Ken Ferry <kenfe...@gmail.com> 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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
