@synchronized(self) {}写法是什么作用

如题：

 

@synchronized(self) {

  。。。 。。。

}

保证此时没有其他线程对self对象进行修改

 

Using the @synchronized Directive

The @synchronized directive is a convenient way to create mutex locks onthe fly in Objective-C code. The @synchronized directive does what any othermutex lock would do—it prevents different threads from acquiring the same lockat the same time. In this case, however, you do not have to create the mutex orlock object directly. Instead, you simply use any Objective-C object as a locktoken, as shown in the following example:

 

- (void)myMethod:(id)anObj

{

    @synchronized(anObj)

    {

        // Everything between thebraces is protected by the @synchronized directive.

    }

}

The object passed to the @synchronized directive is a unique identifierused to distinguish the protected block. If you execute the preceding method intwo different threads, passing a different object for the anObj parameter oneach thread, each would take its lock and continue processing without beingblocked by the other. If you pass the same object in both cases, however, oneof the threads would acquire the lock first and the other would block until thefirst thread completed the critical section.

 

As a precautionary measure, the @synchronized block implicitly adds anexception handler to the protected code. This handler automatically releasesthe mutex in the event that an exception is thrown. This means that in order touse the @synchronized directive, you must also enable Objective-C exceptionhandling in your code. If you do not want the additional overhead caused by theimplicit exception handler, you should consider using the lock classes.

 

For more information about the @synchronized directive, see TheObjective-C Programming Language.

 

The objective C language level synchronization uses the mutex, just likeNSLock does. Semantically there are some small technical differences, but it isbasically correct to think of them as two seperate interface implemented on topof a common (more primitive) entity.

 

In particular with an NSLock you have an explicit lock whereas with@synchronize you have an implicit lock associated with the object you are usingto synchronize. The benefit of the language level locking is the compilerunderstands it so it can deal with scoping issues, but mechanically they arethe behave basically the same.

 

You can think of @synchronize as basically a compiler rewrite:

 

- (NSString *)myString {

  @synchronized(self) {

    return [[myString retain]autorelease];

  }

}

is transformed into:

 

- (NSString *)myString {

  NSString *retval = nil;

  pthread_mutex_t *self_mutex =LOOK_UP_MUTEX(self);

  pthread_mutex_lock(self_mutex);

  retval = [[myString retain]autorelease];

  pthread_mutex_unlock(self_mutex);

  return retval;

}

That is not exactly correct because the actual transform is more complexand uses recursive locks, but it should get the point across.