问题
static pthread_mutex_t gLock; //global
pthread_mutex_init(&gLock,NULL); //in init
pthread_mutex_lock(&gLock);
for(int i=0;i<[message count];i++)
CFSetAddValue(mSet, [message objectAtIndex:i]);
pthread_mutex_unlock(&gLock);
My cocoa application is going in not responding mode with pthread_mutex_t.
@synchronized(mSet)
{
for(int i=0;i<[message count];i++)
CFSetAddValue(mSet, [message objectAtIndex:i]);
}
My application is working fine with synchronized block.
Why?
回答1:
You're comparing a global lock (one lock for all instances) to an object level recursive lock (one lock per instance, which may be acquired multiple times from the same thread). These are not generally interchangeable -- they operate and protect very different from each other.
The good news is, you can use pthread_mutex_t
as a recursive lock which is unique to each instance in order to achieve the same degree of protection as @synchronized
. Using pthread_mutex_t
also makes lock acquisitions much, much faster.
To achieve the same effect as @synchronized
using a pthread mutex, declare pthread_mutex_t gLock
as an instance variable, then initialize it as a recursive mutex in -init
. Finally, destroy the mutex in -dealloc
.
Of course, sub- and base- classes may need access to this lock if they relied on the semantics of @synchronized
to do the right thing through the object hierarchy.
@synchronized
is veeeeeeery slow in comparison to a recursive pthread mutex (last I checked).
回答2:
Justin is right; there is also another detail, however, which is exception handling. From https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Multithreading/ThreadSafety/ThreadSafety.html comes this tip:
As a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. This means that in order to use the @synchronized directive, you must also enable Objective-C exception handling in your code. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes.
If [message count]
can raise exceptions that could jump over your unlock code and wedge you up.
来源:https://stackoverflow.com/questions/9463525/pthread-mutex-t-vs-synchronized-block