-
@sychronized
可以在多线程下进行递归调用，那么是怎么做到在多线程下进行递归调用的呢？我们通过终端编译然后进行分析。首先，在main.m中，调用
NSObject *obj = [NSObject new];
@synchronized (obj) {
}
在main.m所在的文件夹中，执行clang -rewrite-objc main.m，在对应的文件夹下，生成了一个main.cpp的文件，打开文件，找到如上代码编译后的代码
{
id _rethrow = 0;
id _sync_obj = (id)obj;
objc_sync_enter(_sync_obj);
try {
struct _SYNC_EXIT {
_SYNC_EXIT(id arg) : sync_exit(arg) {}
~_SYNC_EXIT() {objc_sync_exit(sync_exit);}
id sync_exit;
} _sync_exit(_sync_obj);
} catch (id e) {_rethrow = e;}
{
struct _FIN { _FIN(id reth) : rethrow(reth) {}
~_FIN() { if (rethrow) objc_exception_throw(rethrow); }
id rethrow;
} _fin_force_rethow(_rethrow);}
}
在源码中，首先执行了 objc_sync_enter(_sync_obj);
下面是一个try-catch块，主要是看try内容，catch的内容主要是异常处理。
在try的内容中，定义了一个结构体_SYNC_EXIT，内部有一个构造函数objc_sync_exit(sync_exit)，在末尾出调用了构造函数_sync_exit(_sync_obj);，那也就是@sychronized这把锁内部最重要的两个函数objc_sync_enter和objc_sync_exit，从源码中去查看对应的函数实现。
int objc_sync_enter(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, ACQUIRE);
ASSERT(data);
data->mutex.lock();
} else {
// @synchronized(nil) does nothing
if (DebugNilSync) {
_objc_inform("NIL SYNC DEBUG: @synchronized(nil); set a breakpoint on objc_sync_nil to debug");
}
objc_sync_nil();
}
return result;
}
int objc_sync_exit(id obj)
{
int result = OBJC_SYNC_SUCCESS;
if (obj) {
SyncData* data = id2data(obj, RELEASE);
if (!data) {
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
} else {
bool okay = data->mutex.tryUnlock();
if (!okay) {
result = OBJC_SYNC_NOT_OWNING_THREAD_ERROR;
}
}
} else {
// @synchronized(nil) does nothing
}
return result;
}
首先，objc_sync_enter和objc_sync_exit对传入的obj进行了判断，如果为空的话，则什么也不做，在注释里也可以看出来。
第二点，无论是enter还是exit，所依赖的数据就是SyncData，通过id2data来获取，enter传入的是ACQUIRE，而exit则是RELEASE。我们继续来看一下SyncData的数据结构
typedef struct alignas(CacheLineSize) SyncData {
struct SyncData* nextData;
DisguisedPtr<objc_object> object;
int32_t threadCount; // number of THREADS using this block
recursive_mutex_t mutex;
} SyncData;
- struct SyncData* nextData; 表示SyncData是一个单向链表，由一连串的节点组成，记录了这一系列的数据
- DisguisedPtr<objc_object> object; 对数据进行了统一的封装
- int32_t threadCount;记录使用block的线程数量
- recursive_mutex_t mutex; 是一把递归锁
在enter中利用nutex进行了加锁，在exit的时候，进行了递归解锁。在内部记录使用了block的线程数量，通过记录线程数据和递归锁来实现多线程递归调用，那么如何通过线程记录和递归锁来实现递归调用的呢？SyncData是因为id2data来得到的，我们就继续看一下id2data的实现，总共分为四部分。
- listp是指向链表的指针，即是链表的头指针。
而lockphe 和listp都来自于sDataLists，sDataLists是StripedMap类型，StripedMap在里面描述了真机是8个，模拟器是64个，是用来缓存带spinlock锁能力的类或者结构体。 - 第一部分
// Check per-thread single-entry fast cache for matching object
bool fastCacheOccupied = NO;
SyncData *data = (SyncData *)tls_get_direct(SYNC_DATA_DIRECT_KEY);
if (data) {
fastCacheOccupied = YES;
if (data->object == object) {
// Found a match in fast cache.
uintptr_t lockCount;
result = data;
lockCount = (uintptr_t)tls_get_direct(SYNC_COUNT_DIRECT_KEY);
if (result->threadCount <= 0 || lockCount <= 0) {
_objc_fatal("id2data fastcache is buggy");
}
switch(why) {
case ACQUIRE: {
lockCount++;
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
break;
}
case RELEASE:
lockCount--;
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)lockCount);
if (lockCount == 0) {
// remove from fast cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, NULL);
// atomic because may collide with concurrent ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
通过注释可以看出fast cache，也就是快速缓存，检查每一条线程的快速缓存。
快速缓存也是从tls里面获取的，通过SYNC_DATA_DIRECT_KEY来获取。通过标识位的方式，如果找到了对应的数据，就将标识为设置为yes，而且判断当前的object与data的object是否相等，如果相等的话，下面的流程跟第二部分是一样的，后续可以看第二部分。
-
第二部分
为匹配数据检查已经拥有锁的每个线程缓存
Check per-thread cache of already-owned locks for matching object
通过fetch_cache获取_objc_pthread_data
// objc per-thread storage
typedef struct {
struct _objc_initializing_classes *initializingClasses; // for +initialize
struct SyncCache *syncCache; // for @synchronize
struct alt_handler_list *handlerList; // for exception alt handlers
char *printableNames[4]; // temporary demangled names for logging
const char **classNameLookups; // for objc_getClass() hooks
unsigned classNameLookupsAllocated;
unsigned classNameLookupsUsed;
// If you add new fields here, don't forget to update
// _objc_pthread_destroyspecific()
} _objc_pthread_data;
SyncData *data;
unsigned int lockCount; // number of times THIS THREAD locked this block
} SyncCacheItem;
typedef struct SyncCache {
unsigned int allocated;
unsigned int used;
SyncCacheItem list[0];
} SyncCache;
_objc_pthread_data是个结构体，结构体中包含SyncCache *syncCache;，看注释可以知道这个是储存的@synchronize相关的数据，其中SyncCache结构体中有一个参数为SyncCacheItem list[0];，在SyncCacheItem中有一个参数为lockCount，记录的就是当前线程锁定此block的次数。
SyncCache *cache = fetch_cache(NO);
if (cache) {
unsigned int I;
for (i = 0; i < cache->used; i++) {
SyncCacheItem *item = &cache->list[I];
if (item->data->object != object) continue;
// Found a match.
result = item->data;
if (result->threadCount <= 0 || item->lockCount <= 0) {
_objc_fatal("id2data cache is buggy");
}
switch(why) {
case ACQUIRE:
item->lockCount++;
break;
case RELEASE:
item->lockCount--;
if (item->lockCount == 0) {
// remove from per-thread cache
cache->list[i] = cache->list[--cache->used];
// atomic because may collide with concurrent ACQUIRE
OSAtomicDecrement32Barrier(&result->threadCount);
}
break;
case CHECK:
// do nothing
break;
}
return result;
}
}
那么这整个第二部分的代码解读就可以理解为遍历cache，在cach中以SyncCacheItem存在，包含SyncData以及锁定此block的次数lockCount，而SyncData保存着我们传递给sychronized这把锁要锁定的对象，跟我们现在要加锁的对象进行对比，如果不相等的话就继续遍历。如果相等就是找到了，然后进入switch结构，ACQUIRE加锁，SyncCacheItem 的lockCount++。RELEASE就进行lockCount--，如果等于0了，就是完全解锁了，把cache里面的数据，调用OSAtomicDecrement32Barrier就是将当前对应的对象的SyncData的记录加锁线程的数量进行-1的操作。
整部分的操作就是从我们的TLS线程的局部空间寻找对应的缓存对象的SyncData，如果找到了对应的SyncData，就进行相应的线程加锁次数的加减操作，然后返回对象，然后 通过id2data就得到了对应的SyncData，然后对当前对象进行加锁减锁
从以上两部分可以看出，数据结构为
然后通过id2data获取syncData，首先从快速缓存中去找，没找到的话，就是从整个线程的缓存中去找，然后遍历cache，找到syncCacheItem，然后通过加锁对象object去跟缓存中的syncData的objc进行对比找到对应的syncData，最后通过syncData里面的mutex进行加锁减锁的操作，threadCount记录的是当前被锁对象的加锁的线程数量。syncCacheItem的lockCount记录的是当前线程对block加锁的数量，即递归加锁的次数。
-
第三部分
从线程缓存中没有找到对应的syncData，则进行第三部分。
SyncData* p;
SyncData* firstUnused = NULL;
for (p = *listp; p != NULL; p = p->nextData) {
if ( p->object == object ) {
result = p;
// atomic because may collide with concurrent RELEASE
OSAtomicIncrement32Barrier(&result->threadCount);
goto done;
}
if ( (firstUnused == NULL) && (p->threadCount == 0) )
firstUnused = p;
}
// no SyncData currently associated with object
if ( (why == RELEASE) || (why == CHECK) )
goto done;
// an unused one was found, use it
if ( firstUnused != NULL ) {
result = firstUnused;
result->object = (objc_object *)object;
result->threadCount = 1;
goto done;
}
listp在开头的时候说过是syncData单向链表的的头指针，从开头部分说的真机是8个，模拟器是64张StripedMap表中去查找，判断每一个节点的object是否与当前要加锁的object相等，相等的话就是当前对象第一次加锁，进行OSAtomicIncrement32Barrier记录线程数量+1，然后进行goto done，如下所示
- goto done部分
if (result) {
// Only new ACQUIRE should get here.
// All RELEASE and CHECK and recursive ACQUIRE are
// handled by the per-thread caches above.
if (why == RELEASE) {
// Probably some thread is incorrectly exiting
// while the object is held by another thread.
return nil;
}
if (why != ACQUIRE) _objc_fatal("id2data is buggy");
if (result->object != object) _objc_fatal("id2data is buggy");
#if SUPPORT_DIRECT_THREAD_KEYS
if (!fastCacheOccupied) {
// Save in fast thread cache
tls_set_direct(SYNC_DATA_DIRECT_KEY, result);
tls_set_direct(SYNC_COUNT_DIRECT_KEY, (void*)1);
} else
#endif
{
// Save in thread cache
if (!cache) cache = fetch_cache(YES);
cache->list[cache->used].data = result;
cache->list[cache->used].lockCount = 1;
cache->used++;
}
}
因为是首次加锁，所以只有ACQUIRE才会走到这里，所以当是RELEASE的时候直接return nil，然后是一些异常判断。
接下来，首先判断快速缓存中是否存在，如果不存在则将该对象存入快速缓存。如果快速缓存中已经存在，则存入线程缓存。
- 第四部分
如果在表里也没有找到相应的数据
posix_memalign((void **)&result, alignof(SyncData), sizeof(SyncData));
result->object = (objc_object *)object;
result->threadCount = 1;
new (&result->mutex) recursive_mutex_t(fork_unsafe_lock);
result->nextData = *listp;
*listp = result;
那就说明这个对象是第一次进来加锁，表中没有对应的数据，初始化线程数=1，关联object对象，初始化一把锁，然后放入单向链表里面。
这是整个id2data的所有内容。首先通过object在快速缓存中去找，如果没有找到，则去整个线程缓存中去找，匹配到相应的syncData则操作线程锁数量的加减，如果在线程缓存中也没有找到，则去相应的listp的表中去寻找，然后对object做对应的操作，如果在线程缓存中没有找到，则去表中去找，如果表中也没有找到，则去初始化一个表然后加入表中。
最后
所以为什么能够多线程递归调用，是因为@sychronized每一条线程都有一把锁，记录在缓存中syncCacheItem然后记录着syncData，每个syncData都有一个mutex的递归锁，每一条线程都可以进行递归调用。而NSRecurseive为什么不在多线程递归调用，是因为它只有这一把锁，而@sychronized每一条线程都有一把锁，可以记录每条线程的枷锁次数，所以可以多线程递归调用。
