now i could put locks around every place where i read it or write
to it (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?
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.
What CPU architecture are we talking about here? I'm not 100% sure,
but I read somewhere that, in general, assignments in C are *not*
guaranteed to be atomic. It works if you're just dealing with a
boolean, since there it's effectively only one bit that gets examined
and changed, and that can't be in an in-between state.
For anything larger than that, it's at least possible they aren't,
and for structs you're pretty much guaranteed to be non-atomic.
However, I don't know for sure, and I wouldn't be surprised if a
pointer and other things that are the current CPU's natural integer's
size were atomic. But as I said, it depends on the CPU you're
deploying to. If you want to be sure, I think there's some atomicity
macros available in one of Apple's headers that are guaranteed to
compile down to atomic instructions. Or you can use a lock or mutex.
If you can expect @synchronized to be there, that'd probably make
it easiest, as then you could just use the object containing this
pointer as the lock target. And anyway, you'll need a lock anyway,
because someone could be accessing the array from another thread
while you're replacing it, and then you'd release it from out under
their feet. Also keep in mind that you also have to lock the objects
*in* the array if they're mutable and accessed from another thread,
or if they could get released on one of the threads.
