Re: pointer assignment inherently atomic ?
Re: pointer assignment inherently atomic ?
- Subject: Re: pointer assignment inherently atomic ?
- From: Bill Bumgarner <email@hidden>
- Date: Sat, 11 Aug 2007 10:14:34 -0700
On Aug 10, 2007, at 12:52 PM, Chase wrote:
i have an NSMutableArray that gets periodically rebuilt in a
background thread.
the main thread or any of several other threads may want read
access to it at any time.
when i rebuild it in the background thread, i am actually building
a new, separate array and once i'm done i swap in the new one for
the old one:
oldarray = realarray;
realarray = newarray; // the swap
[oldarray release];
Pointer assignments are atomic. The cache coherency issue isn't one
of atomicity, but one of state synchronization -- you'll never get
half a pointer from a different core's cache.
However, the code above is not atomic in the context of Obj-C. As
someone else pointed out, you have the potential for a race condition
in the above code.
As well, somewhere you have a -retain of that realarray or your code
will crash. And that yields another potential race condition.
Without GC, you have to consider retain count management as an
integral, but inherently non-atomic, part of the overall state
management code.
With GC, this all goes away. Pointer assignments are atomic in both
the context of the actual bytes being moved into a location in memory
and in the context of ensuring an object remains alive.
"Transferring" an object between two threads complicates things
further. In particular autorelease pools do provide a means of
transferring ownership. You must retain the object in thread A and
then let thread B manage that reference once it has the object. GC
eliminates this issue, too.
b.bum
_______________________________________________
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