Re: [RESOLVED] pointer assignment inherently atomic ?
Re: [RESOLVED] pointer assignment inherently atomic ?
- Subject: Re: [RESOLVED] pointer assignment inherently atomic ?
- From: "Chase" <email@hidden>
- Date: Sat, 11 Aug 2007 04:08:16 +0000
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 is exactly right. i've just been extremely lucky that it hasn't
crashed yet because of this.
as a concrete example of a spot where it's just begging to fail...
i have several places where i iterate through the array, like so...
for (i=0; i<[theArray count]; i++)
{
// if the new array is swapped in right here -- just after the check
against count
// and just before we try to access the object at index i -- it is
possible that
// index i is beyond the bounds of the newly swapped in array we're
about to access.
// like, for example, if the first array has a count of 10 and the
new array has a
// count of 5 and i is at 7...
[[theArray objectAtIndex:i] doSomething];
}
if the background thread swaps in a new array while i'm in the middle
of this, and the new array count is less, i could easily walk past the
bounds of the new array.
after Alastair pointed this out, i noticed several different similar
potential crashes all stemming from a lack of locks around the array.
i think my brain was off-duty when i decided it was okay to set it up
that way. ;)
mainly, i think i was just desperate to avoid cluttering up the code
with locks and unlocks. i know @synchronized is cleaner in terms of
code clutter, but the lock/unlock paradigm is what i'm used to for
thread synchronization. i think it just makes more sense in my mind to
see the words "lock" and "unlock" around thread-sensitive stuff.
anyway, thanks to everyone to who chimed in.
- chase
_______________________________________________
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