这是并发控制方案的系列文章，介绍了各种锁的使用及优缺点。
OSSpinLock、os_unfair_lock、pthread_mutex_t、pthread_cond_t、pthread_rwlock_t 是值类型，不是引用类型。这意味着使用 = 会进行复制，使用复制的可能导致闪退。pthread 函数认为其一直处于初始化的内存地址，将其移动到其他内存地址会产生问题。使用copy的OSSpinLock不会崩溃，但会得到一个全新的锁。
如果你对线程、进程、串行、并发、并行、锁等概念还不了解，建议先查看以下文章：
自旋锁（Spin Lock）是一种简单、高效、线程安全的同步原语（synchronization primitive），其在等待时会反复检查锁的状态，直到解锁。
锁已经加锁时，多数锁会让尝试加锁的线程进入睡眠状态，释放锁时再将其唤醒。这在多数情况下都是合适的，但如果临界区域特别小，耗时极短，常规锁的休眠、唤醒操作将变得昂贵。此时，自旋锁的忙等性能更高。
Spin lock 使用 memory barrier 保护共享资源，锁定期间可能发生抢占（preemption）。
为了方便本系列文章介绍其他锁，先创建一个需要线程同步的基类，每次介绍锁时只需继承自该基类即可。
class BaseDemo {
private var ticketsCount = 25
private var money = 100
// MARK: - Money
func moneyTest() {
let queue = DispatchQueue.global(qos: .utility)
queue.async {
for _ in 1...10 {
self.saveMoney()
}
}
queue.async {
for _ in 1...10 {
self.drawMoney()
}
}
}
func drawMoney() {
var oldMoney = money
sleep(1)
oldMoney -= 20
money = oldMoney
print("取20元，还剩余\(oldMoney)元 -- \(Thread.current)")
}
func saveMoney() {
var oldMoney = money
sleep(1)
oldMoney += 50
money = oldMoney
print("存50元，还剩\(oldMoney)元 -- \(Thread.current)")
}
// MARK: - Sale Ticket
func ticketTest() {
let queue = DispatchQueue.global(qos: .utility)
queue.async {
for _ in 1...5 {
self.saleTicket()
}
}
queue.async {
for _ in 1...5 {
self.saleTicket()
}
}
queue.async {
for _ in 1...5 {
self.saleTicket()
}
}
}
func saleTicket() {
var oldTicketsCount = ticketsCount
sleep(1)
oldTicketsCount -= 1
ticketsCount = oldTicketsCount
print("还剩\(oldTicketsCount)张票 -- \(Thread.current)")
}
func otherTest() {
}
}
即使执行
i = i +1这样简单的命令，也可分为三个指令：
- 读取 i 的值。
- 对 i 的值进行加一。
- 将值写入 i。
执行上述任一指令时都可能发生上下文切换，也可能多个线程同时操作。如，线程A读取 i 的值，线程B同时读取 i 的值，进行加一后，线程A写入后，线程B也进行写入。这会导致 i 的值只进行了一次加一操作。想要解决这一问题，应采取线程同步措施。
调用moneyTest()、ticketTest()函数时触发并发存取款、卖票，会产生不可预期的结果。后续部分只需要在调用基类方法时加锁、解锁即可。
OSSpinLock是数值类型，未锁定时值为零，锁定时值为非零。使用以下代码创建OSSpinLock属性：
private var moneyLock: OSSpinLock = OS_SPINLOCK_INIT
private var ticketLock: OSSpinLock = OS_SPINLOCK_INIT
如果是在 Objective-C 中使用自旋锁，需导入
#import <libkern/OSAtomic.h>头文件。
加锁时调用OSSpinLockLock()、OSSpinLockTry()。如果锁已经加锁，OSSpinLockLock()函数会忙等（busy waiting），其也会采取一些策略避免优先级反转，但对于执行时间长、竞争激烈的任务效率不高。如果已经加锁，OSSpinLockTry()立即返回 false，不会忙等。
加锁方法如下：
os_unfair_lock_lock(&moneyLock)
解锁时调用OSSpinLockUnlock()函数。
os_unfair_lock_unlock(&moneyLock)
更新后，OSSpinLockDemo.swift文件如下：
class OSSpinLockDemo: BaseDemo {
private var moneyLock: OSSpinLock = OS_SPINLOCK_INIT
private var ticketLock: OSSpinLock = OS_SPINLOCK_INIT
override func drawMoney() {
OSSpinLockLock(&moneyLock)
super.drawMoney()
OSSpinLockUnlock(&moneyLock)
}
override func saveMoney() {
OSSpinLockLock(&moneyLock)
super.saveMoney()
OSSpinLockUnlock(&moneyLock)
}
override func saleTicket() {
OSSpinLockLock(&ticketLock)
super.saleTicket()
OSSpinLockUnlock(&ticketLock)
}
}
未加锁时，执行结果可能出现错误；加锁后多次执行，结果均为正确。
当条件合适时，自旋锁性能最佳。自旋锁的问题在于，当一个线程持有锁时，其他尝试加锁的线程会浪费 CPU 资源忙等。
如果临界区域很小，一般不会出现问题。如果一个线程加锁后，没有其他线程尝试获取锁，也不会出现问题。如果其他线程也尝试获取锁，其必须等待持有锁的线程执行完毕。在单核的设备上，这一问题更为突出。因为持有锁的线程必须等待自旋的线程使用完分配的时间片才能执行。
也可以采取一些措施减少此类问题。例如，对自旋次数计数，达到一定次数后，将资源让步于调度程序。OSSpinLock实现了一些类似策略，在大多数情况下，OSSpinLock运行良好，甚至可以避免优先级反转。
优先级反转指低优先级线程持有锁，高优先级线程被锁阻塞、或等待低优先级线程执行结果。在常规锁中，只是高优先级线程需等待低优先级线程执行，由于低优先级线程被分配资源少，可能需要等待很长时间。但在 spin lock 中，这一问题更为严峻。因为等待锁的高优先级线程等待时一直自旋，占用 CPU 资源，低优先级线程分配到的资源更少，进一步导致锁长时间不能释放。
OSSpinLock会采取一些策略缓和优先级反转的问题。例如，自旋一定次数后，如果加锁线程进度没有变化，停止自旋。dispatch queue 和 pthread mutex 通过自动提高持有锁线程的优先级解决优先级反转问题。由于信号量（如，dispatch_semaphore_t）不知道哪个线程正在执行工作，其不会进行类似处理。
iOS 8 内核升级后推出了 Quality Of Service（简称 QOS）。QOS 允许NSOperation、NSThread、dispatch queue 和 pthread 将任务分为不同优先级。拥有高 QOS 的线程永远不会衰减为低 QOS，调度器永远会优先为高 QOS 的线程分配资源。因此，处于自旋的 QOS 线程会持续忙等，持有锁的低 QOS 的线程得不到资源执行任务，导致自旋锁不再安全。
为此，iOS 10 使用os_unfair_lock取代了OSSpinLock。下一篇文章将介绍os_unfair_lock。
Demo名称：Synchronization
源码地址：https://github.com/pro648/BasicDemos-iOS/tree/master/Synchronization
参考资料：