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:
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:
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.
