-
@sychronized
可以在多線程下進行遞歸調(diào)用，那么是怎么做到在多線程下進行遞歸調(diào)用的呢？我們通過終端編譯然后進行分析。首先，在main.m中，調(diào)用
NSObject *obj = [NSObject new];
@synchronized (obj) {
}
在main.m所在的文件夾中，執(zhí)行clang -rewrite-objc main.m，在對應(yīng)的文件夾下，生成了一個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);}
}
在源碼中，首先執(zhí)行了 objc_sync_enter(_sync_obj);
下面是一個try-catch塊，主要是看try內(nèi)容，catch的內(nèi)容主要是異常處理。
在try的內(nèi)容中，定義了一個結(jié)構(gòu)體_SYNC_EXIT，內(nèi)部有一個構(gòu)造函數(shù)objc_sync_exit(sync_exit)，在末尾出調(diào)用了構(gòu)造函數(shù)_sync_exit(_sync_obj);，那也就是@sychronized這把鎖內(nèi)部最重要的兩個函數(shù)objc_sync_enter和objc_sync_exit，從源碼中去查看對應(yīng)的函數(shù)實現(xiàn)。
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，所依賴的數(shù)據(jù)就是SyncData，通過id2data來獲取，enter傳入的是ACQUIRE，而exit則是RELEASE。我們繼續(xù)來看一下SyncData的數(shù)據(jù)結(jié)構(gòu)
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是一個單向鏈表，由一連串的節(jié)點組成，記錄了這一系列的數(shù)據(jù)
- DisguisedPtr<objc_object> object; 對數(shù)據(jù)進行了統(tǒng)一的封裝
- int32_t threadCount;記錄使用block的線程數(shù)量
- recursive_mutex_t mutex; 是一把遞歸鎖
在enter中利用nutex進行了加鎖，在exit的時候，進行了遞歸解鎖。在內(nèi)部記錄使用了block的線程數(shù)量，通過記錄線程數(shù)據(jù)和遞歸鎖來實現(xiàn)多線程遞歸調(diào)用，那么如何通過線程記錄和遞歸鎖來實現(xiàn)遞歸調(diào)用的呢？SyncData是因為id2data來得到的，我們就繼續(xù)看一下id2data的實現(xiàn)，總共分為四部分。
- listp是指向鏈表的指針，即是鏈表的頭指針。
而lockphe 和listp都來自于sDataLists，sDataLists是StripedMap類型，StripedMap在里面描述了真機是8個，模擬器是64個，是用來緩存帶spinlock鎖能力的類或者結(jié)構(gòu)體。 - 第一部分
// 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來獲取。通過標識位的方式，如果找到了對應(yīng)的數(shù)據(jù)，就將標識為設(shè)置為yes，而且判斷當前的object與data的object是否相等，如果相等的話，下面的流程跟第二部分是一樣的，后續(xù)可以看第二部分。
-
第二部分
為匹配數(shù)據(jù)檢查已經(jīng)擁有鎖的每個線程緩存
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是個結(jié)構(gòu)體，結(jié)構(gòu)體中包含SyncCache *syncCache;，看注釋可以知道這個是儲存的@synchronize相關(guān)的數(shù)據(jù)，其中SyncCache結(jié)構(gòu)體中有一個參數(shù)為SyncCacheItem list[0];，在SyncCacheItem中有一個參數(shù)為lockCount，記錄的就是當前線程鎖定此block的次數(shù)。
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的次數(shù)lockCount，而SyncData保存著我們傳遞給sychronized這把鎖要鎖定的對象，跟我們現(xiàn)在要加鎖的對象進行對比，如果不相等的話就繼續(xù)遍歷。如果相等就是找到了，然后進入switch結(jié)構(gòu)，ACQUIRE加鎖，SyncCacheItem 的lockCount++。RELEASE就進行l(wèi)ockCount--，如果等于0了，就是完全解鎖了，把cache里面的數(shù)據(jù)，調(diào)用OSAtomicDecrement32Barrier就是將當前對應(yīng)的對象的SyncData的記錄加鎖線程的數(shù)量進行-1的操作。
整部分的操作就是從我們的TLS線程的局部空間尋找對應(yīng)的緩存對象的SyncData，如果找到了對應(yīng)的SyncData，就進行相應(yīng)的線程加鎖次數(shù)的加減操作，然后返回對象，然后 通過id2data就得到了對應(yīng)的SyncData，然后對當前對象進行加鎖減鎖
從以上兩部分可以看出，數(shù)據(jù)結(jié)構(gòu)為
然后通過id2data獲取syncData，首先從快速緩存中去找，沒找到的話，就是從整個線程的緩存中去找，然后遍歷cache，找到syncCacheItem，然后通過加鎖對象object去跟緩存中的syncData的objc進行對比找到對應(yīng)的syncData，最后通過syncData里面的mutex進行加鎖減鎖的操作，threadCount記錄的是當前被鎖對象的加鎖的線程數(shù)量。syncCacheItem的lockCount記錄的是當前線程對block加鎖的數(shù)量，即遞歸加鎖的次數(shù)。
-
第三部分
從線程緩存中沒有找到對應(yīng)的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表中去查找，判斷每一個節(jié)點的object是否與當前要加鎖的object相等，相等的話就是當前對象第一次加鎖，進行OSAtomicIncrement32Barrier記錄線程數(shù)量+1，然后進行g(shù)oto 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，然后是一些異常判斷。
接下來，首先判斷快速緩存中是否存在，如果不存在則將該對象存入快速緩存。如果快速緩存中已經(jīng)存在，則存入線程緩存。
- 第四部分
如果在表里也沒有找到相應(yīng)的數(shù)據(jù)
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;
那就說明這個對象是第一次進來加鎖，表中沒有對應(yīng)的數(shù)據(jù)，初始化線程數(shù)=1，關(guān)聯(lián)object對象，初始化一把鎖，然后放入單向鏈表里面。
這是整個id2data的所有內(nèi)容。首先通過object在快速緩存中去找，如果沒有找到，則去整個線程緩存中去找，匹配到相應(yīng)的syncData則操作線程鎖數(shù)量的加減，如果在線程緩存中也沒有找到，則去相應(yīng)的listp的表中去尋找，然后對object做對應(yīng)的操作，如果在線程緩存中沒有找到，則去表中去找，如果表中也沒有找到，則去初始化一個表然后加入表中。
最后
所以為什么能夠多線程遞歸調(diào)用，是因為@sychronized每一條線程都有一把鎖，記錄在緩存中syncCacheItem然后記錄著syncData，每個syncData都有一個mutex的遞歸鎖，每一條線程都可以進行遞歸調(diào)用。而NSRecurseive為什么不在多線程遞歸調(diào)用，是因為它只有這一把鎖，而@sychronized每一條線程都有一把鎖，可以記錄每條線程的枷鎖次數(shù)，所以可以多線程遞歸調(diào)用。
