iOS 原理探究-互斥锁

joker_king
4,582 阅读8分钟

在编程中，引入了对象互斥锁的概念，来保证共享数据操作的完整性。每个对象都对应于一个可称为" 互斥锁" 的标记，这个标记用来保证在任一时刻，只能有一个线程访问该对象。对于互斥锁，如果资源已经被占用，资源申请者只能进入睡眠状态。

互斥锁又分为递归锁和非递归锁。

  • 递归锁是一种可以多次被同一线程持有的锁。
  • 非递归锁是只能一个线程锁定一次，想要再次锁定，就必须先要解锁，否则就会发生死锁现象。

非递归锁

pthread_mutex

创建和销毁

pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;//静态初始化互斥量
int pthread_mutex_init(pthread_mutex_t*mutex,pthread_mutexattr_t*attr);//动态初始化互斥量
int pthread_mutex_destory(pthread_mutex_t*mutex);//注销互斥量

加锁和解锁

int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_trylock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t*mutex);
  • pthread_mutex_lock`给互斥量加锁。当另一个线程来获取这个锁的时候，发现这个锁已经加锁，那么这个线程就会进入休眠状态，直到这个互斥量被解锁，线程才会重新被唤醒。
  • pthread_mutex_trylock当互斥量已经被锁住时调用该函数将返回错误代码EBUSY，如果当前互斥量没有被锁，则会执行和pthread_mutex_lock一样的效果。
  • pthread_mutex_unlock对互斥量进行解锁。

NSLock

我们在swift版本开源的CoreFoundation框架下我们可以看到关于NSLock的完整定义。

注意：以下代码只摘取了关键部分，其他兼容性代码已被省略。

创建

public override init() {
    pthread_cond_init(timeoutCond, nil)
    pthread_mutex_init(timeoutMutex, nil)
}

销毁

deinit {
    pthread_mutex_destroy(mutex)
}

加锁

open func lock() {
    pthread_mutex_lock(mutex)
}

解锁

open func unlock() {
    pthread_mutex_unlock(mutex)
}

lock(before limit: Date)

open func lock(before limit: Date) -> Bool {
    if pthread_mutex_trylock(mutex) == 0 {
        return true
    }
    return timedLock(mutex: mutex, endTime: limit, using: timeoutCond, with:
}

这个函数的主要作用就是在某一个时间点之前不断的尝试加锁，主要做了下面几件事情。

  • pthread_mutex_trylock尝试加锁，如果加锁成功则直接返回true。
  • timedLock通过一层while循环调用pthread_mutex_trylock不断尝试加锁。如果失败失败则返回false，如果成功则返回true。

通过上述代码我们可以发现NSLock底层呢，其实也就是基于pthread_mutex进行了一次面向对象的封装。因为他是比pthread_mutex更高一级的API，所以在性能方面呢比pthread_mutex稍微差一点。

NSCondition

NSCondition和NSLock一样都是基于pthread_mutex进行面向对象分装的一个非递归的互斥锁，在swift版本开源的CoreFoundation框架下我们同样可以找到相关的开源代码。

条件对象既充当给定线程中的锁又充当检查点。锁在测试条件并执行条件触发的任务时保护您的代码。检查点行为要求条件在线程继续执行其任务之前为真。条件不成立时，线程将阻塞。它保持阻塞状态，直到另一个线程向条件对象发出信号为止。

注意：以下代码只摘取了关键部分，其他兼容性代码已被省略。

创建

public override init() {
    pthread_cond_init(cond, nil)//初始化条件变量
    pthread_mutex_init(mutex, nil)//初始化互斥锁
}

销毁

deinit {
    pthread_mutex_destroy(mutex)
}

加锁

open func lock() {
    pthread_mutex_lock(mutex)
}

解锁

open func unlock() {
    pthread_mutex_unlock(mutex)
}

它在NSLock的基础上又增加了些新的功能。

等待

open func wait() {
    pthread_cond_wait(cond, mutex)
}

阻塞当前线程，直到接收到条件信号为止。

open func wait(until limit: Date) -> Bool {
    guard var timeout = timeSpecFrom(date: limit) else {
        return false
    }
    return pthread_cond_timedwait(cond, mutex, &timeout) == 0
}

阻塞当前线程，直到接收到条件信号或达到指定的时间限制为止。

激活

signal

open func signal() {
    pthread_cond_signal(cond)
}

我们通过查阅pthread开源代码如下

/*
 * Signal a condition variable, waking only one thread.
 */
PTHREAD_NOEXPORT_VARIANT
int
pthread_cond_signal(pthread_cond_t *ocond)
{
    return _pthread_cond_signal(ocond, false, MACH_PORT_NULL);
}

发信号通知条件变量，仅唤醒一个线程。

broadcast

open func broadcast() {
    pthread_cond_broadcast(cond) // wait  signal
}

我们在pthread的开源代码中找到这么代码。

/*
 * Signal a condition variable, waking up all threads waiting for it.
 */
PTHREAD_NOEXPORT_VARIANT
int
pthread_cond_broadcast(pthread_cond_t *ocond)
{
    return _pthread_cond_signal(ocond, true, MACH_PORT_NULL);
}

苹果的注释告诉我们这是一个（发信号通知条件变量，唤醒所有等待它的线程。）的函数。

NSConditionLock

使用NSConditionLock对象，可以确保线程仅在满足特定条件时才能获取锁。 一旦获得了锁并执行了临界区的代码，线程就可以放弃该锁并将关联条件设置为新的条件。 条件本身是任意的：您可以根据应用程序的需要定义它们。

NSConditionLock是NSCondition的升级版，其内部持有了一个条件锁NSCondition。

internal var _cond = NSCondition()//内存持有的条件锁
internal var _value: Int//条件变量
internal var _thread: _swift_CFThreadRef?//当前的线程

加锁

open func lock() {
		let _ = lock(before: Date.distantFuture)
}

其内部是调用lock(before limit: Date) -> Bool来完成的。

open func lock(before limit: Date) -> Bool {
        _cond.lock()
        while _thread != nil {
            if !_cond.wait(until: limit) {
                _cond.unlock()
                return false
            }
        }
        _thread = pthread_self()
        _cond.unlock()
        return true
}

这个函数做了以下几件事情。

  • 首先调用条件锁加锁，保证接下来代码的线程安全性。然后判断当前是否有线程正在运行。
  • 如果有线程正在运行，然后调用条件锁阻塞当前线程。如果条件不成立，获取当前正在运行的线程赋值_thread属性，然后对条件锁进行一个unlock解锁的操作。
  • 这里主要是保障条件变量的线程安全性。

解锁

    open func unlock() {
        _cond.lock()
#if os(Windows)
        _thread = INVALID_HANDLE_VALUE
#else
        _thread = nil
#endif
        _cond.broadcast()
        _cond.unlock()
    }

  • 首先调用NSCondition的lock方法给接下来的临界区加锁。

  • 对_thread属性置为nil。

  • 发信号通知条件变量，唤醒所有等待它的线程。

  • 调用NSCondition的unlock方法解锁。

lockWhenCondition:

open func lock(whenCondition condition: Int) {
		let _ = lock(whenCondition: condition, before: Date.distantFuture)
}

其内部调用了lock(whenCondition condition: Int, before limit: Date) -> Bool

lockWhenCondition: beforeDate:

open func lock(whenCondition condition: Int, before limit: Date) -> Bool {
        _cond.lock()
        while _thread != nil || _value != condition {
            if !_cond.wait(until: limit) {
                _cond.unlock()
                return false
            }
        }
#if os(Windows)
        _thread = GetCurrentThread()
#else
        _thread = pthread_self()
#endif
        _cond.unlock()
        return true
    }

这里和上面的lock实现原理差不多，只是多了一个_value != condition条件的判断。

unlockWithCondition:

    open func unlock(withCondition condition: Int) {
        _cond.lock()
#if os(Windows)
        _thread = INVALID_HANDLE_VALUE
#else
        _thread = nil
#endif
        _value = condition
        _cond.broadcast()
        _cond.unlock()
    }

这里的实现逻辑和unlock的相同，只是多了一步修改条件变量的步骤_value = condition。

tryLock

open func tryLock(whenCondition condition: Int) -> Bool {
		return lock(whenCondition: condition, before: Date.distantPast)
}

和lockWhenCondition一样内部都是通过调用lock(whenCondition condition: Int, before limit: Date) -> Bool实现的。

递归锁

NSRecursiveLock

我们有幸得到了NSRecursiveLock底层源码，我们一起来看看它是如何实现递归的。

注意：以下代码只截取了关键部分。

创建

public override init() {
    super.init()

    withUnsafeMutablePointer(to: &attrib) { attrs in
        pthread_mutexattr_init(attrs)
        pthread_mutexattr_settype(attrs, Int32(PTHREAD_MUTEX_RECURSIVE))
        pthread_mutex_init(mutex, attrs)
    }
}
  • pthread_mutexattr_settype(attrs, Int32(PTHREAD_MUTEX_RECURSIVE))这是一句关键性的代码，通过这个type来区分是否是递归锁。
#define PTHREAD_MUTEX_NORMAL		0     //普通非递归锁
#define PTHREAD_MUTEX_ERRORCHECK	1
#define PTHREAD_MUTEX_RECURSIVE		2   //递归锁
#define PTHREAD_MUTEX_DEFAULT		PTHREAD_MUTEX_NORMAL   //默认是普通非递归锁

加锁

open func lock() {
    pthread_mutex_lock(mutex)
}

底层是调用了pthread加锁函数。

解锁

open func unlock() {
    pthread_mutex_unlock(mutex)
}

销毁

deinit {
    pthread_mutex_destroy(mutex)
}

总结

NSRecursiveLock底层就是对pthread_mutex的封装，通过设置标识来区分是否为递归锁。

递归锁的实现原理

在pthread我们通过搜索PTHREAD_MUTEX_RECURSIVE递归类型可找到如下代码。

PTHREAD_ALWAYS_INLINE
static inline bool
_pthread_mutex_is_recursive(_pthread_mutex *mutex)
{
	return (mutex->mtxopts.options.type == PTHREAD_MUTEX_RECURSIVE);
}

通过类型匹配，返回当前的锁是否是递归锁。

递归加锁的流程

我们在通过从pthread_mutex_lock以此查看源码，看是否能找到调用_pthread_mutex_is_recursive的地方。

pthread_mutex_lock->_pthread_mutex_firstfit_lock->_pthread_mutex_firstfit_lock_slow->_pthread_mutex_lock_handle_options

在_pthread_mutex_lock_handle_options中，找到了这个函数。

static int
_pthread_mutex_lock_handle_options(_pthread_mutex *mutex, bool trylock,
		uint64_t *tidaddr)
{
	if (mutex->mtxopts.options.type == PTHREAD_MUTEX_NORMAL) {
		// NORMAL does not do EDEADLK checking
		return 0;
	}

	uint64_t selfid = _pthread_selfid_direct();
	if (os_atomic_load(tidaddr, relaxed) == selfid) {
		if (_pthread_mutex_is_recursive(mutex)) {
			if (mutex->mtxopts.options.lock_count < USHRT_MAX) {
				mutex->mtxopts.options.lock_count += 1;
				return mutex->mtxopts.options.lock_count;
			} else {
				return -EAGAIN;
			}
		} else if (trylock) { /* PTHREAD_MUTEX_ERRORCHECK */
			// <rdar://problem/16261552> as per OpenGroup, trylock cannot
			// return EDEADLK on a deadlock, it should return EBUSY.
			return -EBUSY;
		} else { /* PTHREAD_MUTEX_ERRORCHECK */
			return -EDEADLK;
		}
	}

	// Not recursive, or recursive but first lock.
	return 0;
}

在这里我们发现如果是递归锁，那么这把锁维护了一个lock_count的引用计数。每加一次锁都会对引用计数执行+1的操作。

这里截取主要逻辑

int
_pthread_mutex_firstfit_lock_slow(_pthread_mutex *mutex, bool trylock)
{
	res = _pthread_mutex_lock_handle_options(mutex, trylock, tidaddr);
	if (res > 0) {
		recursive = 1;
		res = 0;
		goto out;
	} else if (res < 0) {
		res = -res;
		goto out;
	}
}

接下来会跳转到out代码块中。

out:
#if PLOCKSTAT
	if (res == 0) {
		PLOCKSTAT_MUTEX_ACQUIRE((pthread_mutex_t *)mutex, recursive, 0);
	} else {
		PLOCKSTAT_MUTEX_ERROR((pthread_mutex_t *)mutex, res);
	}
#endif
	return res;
}

我们发现当res为0，也就是确定是递归锁的时候，会对当前的锁进行一次持有。可以理解为对锁的引用计数加1。

递归解锁的流程

pthread_mutex_unlock->_pthread_mutex_firstfit_unlock_slow->_pthread_mutex_firstfit_unlock_updatebits->_pthread_mutex_unlock_handle_options

同理，我们发现当我们在调用解锁的函数时lock_count会做一次-1的操作。再判断是递归锁和lock_countda大于0时返回1。

static int
_pthread_mutex_unlock_handle_options(_pthread_mutex *mutex, uint64_t *tidaddr)
{
	if (mutex->mtxopts.options.type == PTHREAD_MUTEX_NORMAL) {
		// NORMAL does not do EDEADLK checking
		return 0;
	}

	uint64_t selfid = _pthread_selfid_direct();
	if (os_atomic_load(tidaddr, relaxed) != selfid) {
		return -EPERM;
	} else if (_pthread_mutex_is_recursive(mutex) &&
			--mutex->mtxopts.options.lock_count) {
		return 1;
	}
	return 0;
}

主要的解锁逻辑

static inline int
_pthread_mutex_firstfit_unlock_updatebits(_pthread_mutex *mutex,
        uint32_t *flagsp, uint32_t **mutexp, uint32_t *lvalp, uint32_t *uvalp)
{
    int res = _pthread_mutex_unlock_handle_options(mutex, tidaddr);
    if (res > 0) {
        // Valid recursive unlock
        if (flagsp) {
            *flagsp = flags;
        }
        PLOCKSTAT_MUTEX_RELEASE((pthread_mutex_t *)mutex, 1);
        return 0;
    } else if (res < 0) {
        PLOCKSTAT_MUTEX_ERROR((pthread_mutex_t *)mutex, -res);
        return -res;
    }

    return 0;
}

当_pthread_mutex_unlock_handle_options返回的结果大于0的时候进行正常的递归解锁操作。可以理解为锁的引用计数加1。

总结

递归锁我们可以简单理解为是一个OC对象，它拥有一个引用计数的属性，当我们进行多层次的递归加锁时，引用计数会加一，每释放一层锁的时候，引用计数会加一，当引用计数为0的时候，这个递归锁就会被释放。等待下一个线程对他的持有。

总结

这里介绍了基于pthread_mutex实现的递归锁以及非递归锁。

  • 非递归锁里面NSLock是基于pthread_mutex实现的。

  • 条件锁NSCondition也是基于pthread_mutex实现的，基础功能和NSLock相似。在NSLock的基础上增加了一些功能。

  • 条件锁NSConditionLock是基于NSCondition实现的，在其基础上进一步的增加了一下其他功能。

  • 递归锁NSRecursiveLock也是基于pthread_mutex实现的。运用了引用计数的思想。通过维护引用计数来达到一个加解锁平衡的状态。

  • 以上代码的分析来自swift版本的CoreFoundation和pthread。均可在苹果的开源代码库下载到。

avatar
文章
阅读
粉丝
相关推荐
线程同步之互斥锁、读写锁、信号量、条件变量、事件
429阅读
 · 
5点赞
线程互斥与同步
331阅读
 · 
0点赞
Go并发编程 - 互斥锁
253阅读
 · 
0点赞
并发编程(二) - Mutex 互斥锁
902阅读
 · 
4点赞
深入理解Go语言中Mutex互斥锁
905阅读
 · 
2点赞
协程与互斥锁: Kotlin Mutex的终极指南
933阅读
 · 
4点赞
进程之间的同步与互斥
901阅读
 · 
0点赞
互斥锁（Mutex）：Go语言中的并发控制工具
297阅读
 · 
0点赞
iOS 锁
949阅读
 · 
9点赞
如何在JSON Schema中实现互斥、共存
1.9k阅读
 · 
15点赞

友情链接：