转载▼标签：
杂谈 | 分类：iOS |
如题：
@synchronized(self) {
。。。 。。。
}
站在用户的角度思考问题，与客户深入沟通，找到钟祥网站设计与钟祥网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都做网站、成都网站制作、成都外贸网站建设、企业官网、英文网站、手机端网站、网站推广、域名注册、网页空间、企业邮箱。业务覆盖钟祥地区。
保证此时没有其他线程对self对象进行修改
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.
