Re: pointer assignment inherently atomic ?
Re: pointer assignment inherently atomic ?
- Subject: Re: pointer assignment inherently atomic ?
- From: Alastair Houghton <email@hidden>
- Date: Fri, 10 Aug 2007 22:36:15 +0100
On 10 Aug 2007, at 20:52, Chase wrote:
can anyone help me with my question of the day:
are pointer assignments inherently atomic ?
It matters little, since the code below is broken even if they are.
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];
Consider the following, with two threads and time running vertically:
Thread 1 Thread 2
----------------------------------
-----------------------------------
oldarray = realarray;
temp = realarray; // The
*old* array...
realarray = newarray; // the swap
[oldarray release];
[temp retain]; // BANG!
This isn't the only order in which things could go wrong. And in
case you're thinking "but I don't use a temporary variable", the
CPU's registers are temporary variables, as are stack-based
parameters... so even if you don't see a temporary, it's there (trust
me).
now i could put locks around every place where i read it or write
to it
Good idea :-)
(lots of code clutter in this particular case), but i'm thinking
that it may not be necessary since the swap will ultimately boil
down to (i think) a single, indivisible cpu instruction (....maybe).
is this a fair assumption?
No.
note that i haven't had any crashes or bugs related to this so far
(over the course of several weeks of development), but i'm worried
it may just be luck.
Yes.
It *is* possible to do many things without locking, but it really is
something that should only be attempted by people with a detailed
knowledge of How Things Really Work (TM). If you're wondering
whether something is or is not atomic, and don't know where to look
yourself for the answer (or know where to look but don't understand
what it says), then you shouldn't be attempting this.
If you're worried about clutter, make an object to manage the arrays
for you, then write methods like:
- (void)setArray:(NSArray *)newArray
{
@synchronized(self) {
NSArray *oldArray = realArray;
realArray = [newArray retain];
[oldArray release];
}
}
- (NSArray *)array
{
@synchronized(self) {
return [[realArray retain] autorelease];
}
}
You'll note that these are basically standard thread-safe Cocoa
accessor patterns; if you use them, all of the synchronization can be
kept in the array management object.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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