Be Aware of Threats to Code Correctness
When using locks and memory barriers,you should always give careful thought to their
placement in your code. Even locks that seem well placed can actually
lull you into a false sense of security. The following series of
examples attempt to illustrate this problem by pointing out the flaws
in seemingly innocuous code. The basic premise is that you have a
mutable array containing a set of immutable objects. Suppose you want
to invoke a method of the first object in the array. You might do so
using the following code:
NSLock* arrayLock = GetArrayLock(); NSMutableArray* myArray = GetSharedArray(); id anObject; [arrayLock lock]; anObject = [myArray objectAtIndex:0]; [arrayLock unlock]; [anObject doSomething];
Because the array is mutable,the lock around the array prevents other
threads from modifying the array until you get the desired object. And
because the object you retrieve is itself immutable,a lock is not
needed around the call to the doSomething method.There is a problem with the preceding example,though. What happens if
you release the lock and another thread comes in and removes all
objects from the array before you have a chance to execute the
doSomething method? In an application without garbage collection,the
object your code is holding Could be released,leaving anObject
pointing to an invalid memory address. To fix the problem,you might
decide to simply rearrange your existing code and release the lock
after your call to doSomething,as shown here:
NSLock* arrayLock = GetArrayLock(); NSMutableArray* myArray = GetSharedArray(); id anObject; [arrayLock lock]; anObject = [myArray objectAtIndex:0]; [anObject doSomething]; [arrayLock unlock];
By moving the doSomething call inside the lock,your code guarantees
that the object is still valid when the method is called.
Unfortunately,if the doSomething method takes a long time to execute,
this Could cause your code to hold the lock for a long time,which
Could create a performance bottleneck.The problem with the code is not that the critical region was poorly
defined,but that the actual problem was not understood. The real
problem is a memory management issue that is triggered only by the
presence of other threads. Because it can be released by another
thread,a better solution would be to retain anObject before releasing
the lock. This solution addresses the real problem of the object being
released and does so without introducing a potential performance
penalty.
NSLock* arrayLock = GetArrayLock(); NSMutableArray* myArray = GetSharedArray(); id anObject; [arrayLock lock]; anObject = [myArray objectAtIndex:0]; [anObject retain]; [arrayLock unlock]; [anObject doSomething]; [anObject release];
