多线程（五）

  • @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的实现，总共分为四部分。


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，然后对当前对象进行加锁减锁

从以上两部分可以看出，数据结构为


image.png

然后通过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每一条线程都有一把锁，可以记录每条线程的枷锁次数，所以可以多线程递归调用。

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 214,504评论 6赞 496
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 91,434评论 3赞 389
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 160,089评论 0赞 349
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 57,378评论 1赞 288
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 66,472评论 6赞 386
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 50,506评论 1赞 292
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 39,519评论 3赞 413
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 38,292评论 0赞 270
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 44,738评论 1赞 307
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,022评论 2赞 329
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,194评论 1赞 342
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 34,873评论 5赞 338
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 40,536评论 3赞 322
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,162评论 0赞 21
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,413评论 1赞 268
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 47,075评论 2赞 365
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 44,080评论 2赞 352