iPhone use of mutexes with asynchronous URL requests

There are several ways to do this. The simplest in your case would probably be to use the @synchronized directive. This will allow you to create a mutex on the fly using an arbitrary object as the lock.

@synchronized(sStaticData) {  // Do something with sStaticData}

Another way would be to use the NSLock class. Create the lock you want to use, and then you will have a bit more flexibility when it comes to acquiring the mutex (with respect to blocking if the lock is unavailable, etc).

NSLock *lock = [[NSLock alloc] init];// ... later ...[lock lock];// Do something with shared data[lock unlock];// Much later[lock release], lock = nil;

If you decide to take either of these approaches it will be necessary to acquire the lock for both reads and writes since you are using NSMutableArray/Set/whatever as a data store. As you've seen NSFastEnumeration prohibits the mutation of the object being enumerated.

But I think another issue here is the choice of data structures in a multi-threaded environment. Is it strictly necessary to access your dictionaries/arrays from multiple threads? Or could the background threads coalesce the data they receive and then pass it to the main thread which would be the only thread allowed to access the data?

If it's possible that any data (including classes) will be accessed from two threads simultaneously you must take steps to keep these synchronized.

Fortunately Objective-C makes it ridiculously easy to do this using the synchronized keyword. This keywords takes as an argument any Objective-C object. Any other threads that specify the same object in a synchronized section will halt until the first finishes.

-(void) doSomethingWith:(NSArray*)someArray {        // the synchronized keyword prevents two threads ever using the same variable    @synchronized(someArray)    {       // modify array    } }

If you need to protect more than just one variable you should consider using a semaphore that represents access to that set of data.

// Get the semaphore.id groupSemaphore = [Group semaphore];@synchronized(groupSemaphore) {    // Critical group code.}

In response to the sStaticData and NSLock answer (comments are limited to 600 chars), don't you need to be very careful about creating the sStaticData and the NSLock objects in a thread safe way (to avoid the very unlikely scenario of multiple locks being created by different threads)?

I think there are two workarounds:

1) You can mandate those objects get created at the start of day in the single root thread.

2) Define a static object that is automatically created at the start of day to use as the lock, e.g. a static NSString can be created inline:

static NSString *sMyLock1 = @"Lock1";

Then I think you can safely use

@synchronized(sMyLock1) {  // Stuff}

Otherwise I think you'll always end up in a 'chicken and egg' situation with creating your locks in a thread safe way?

Of course, you are very unlikely to hit any of these problems as most iPhone apps run in a single thread.

I don't know about the [Group semaphore] suggestion earlier, that might also be a solution.