ios之線程安全

@synchronized(self) {} 這種寫法是什么作用？

如題：

@synchronized(self) {
。。。 。。。
}

站在用戶的角度思考問題，與客戶深入溝通，找到鐘祥網(wǎng)站設(shè)計(jì)與鐘祥網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)頁空間、企業(yè)郵箱。業(yè)務(wù)覆蓋鐘祥地區(qū)。

保證此時(shí)沒有其他線程對self對象進(jìn)行修改

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

- (void)myMethod:(id)anObj
{
@synchronized(anObj)
{
// Everything between the braces is protected by the @synchronized directive.
}
}
The object passed to the @synchronized directive is a unique identifier used to distinguish the protected block. If you execute the preceding method in two different threads, passing a different object for the anObj parameter on each thread, each would take its lock and continue processing without being blocked by the other. If you pass the same object in both cases, however, one of the threads would acquire the lock first and the other would block until the first thread completed the critical section.

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.

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

The objective C language level synchronization uses the mutex, just like NSLock does. Semantically there are some small technical differences, but it is basically correct to think of them as two seperate interface implemented on top of 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 using to synchronize. The benefit of the language level locking is the compiler understands it so it can deal with scoping issues, but mechanically they are the 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);
returnretval;
}

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