Avoid copying NSMutableArray for reading with multithreaded writes

Question

I have a class that uses a mutable array that is modified once after a lot of reads (new items arrive).

The problem is that when times comes to mutate the array, reads keep coming.

Currently to avoid this issue every time it reads something it does so over a copy:

[[theArray copy] operation] //operation being indexOfObject:, objectAtIndex: objectsAtIndexes:, etc.

The copy is becoming really expensive, especially when there is no need to (all those times when the array is not being mutated).

How can I lock the array to delay the access to it when is being mutated?

Answer 1

Put all your array accesses onto a serial dispatch queue. That will prevent any two operations from occuring at the same time. See "Eliminating Lock-based Code" in the Concurrency Programming Guide.

If you can require iOS >= 4.3, you can use a concurrent custom queue and dispatch barriers for the mutation operations. This will allow the reads to happen simultaneously, but when a write is necessary they'll be held up until the write finishes. The block submitted as a barrier essentially executes serially on a concurrent queue -- it will not begin until all previous blocks have finished, nor will any subsequent blocks begin until the barrier block completes. (This is the GCD version of the read-write lock that Justin mentions.) I direct you to the inimitable Mike Ash for samples of this.

Answer 2

The simplest approach is to use @synchronized, like this:

-(void) accessTheArray {
    MyClass *obj;
    @synchronized(theArray) {
        obj = [theArray objectAtIndex:...];
    }
    [obj someMessage];
}

EDIT: If not using ARC, you might want to retain/autorelease the object, otherwise it might be removed from the array (and released) before someMessage is called (thanks for omz for this excellent comment).

Answer 3

in this case, you would consider using a read/write lock. Cocoa doesn't provide them, but pthread_rwlock_t is available in pthreads interfaces -- declared in pthread.h. note that this is going to be much more efficient (for your usage) than @synchronized, or even a plain lock.