持续创造，加速生长！这是我参加「日新方案 · 10 月更文应战」的第4天，点击检查活动概况

前言

  • iOS中关于多线程相关的文章不胜枚举.
  • 诚然, 把握了iOS中的GCD相关API, 不论开发语言是Objective-C还是Swift, 都能够处理绝大多数业务开发中的多线程场景.
  • 但是, 作为一个有追求的iOS开发者, 除了把握常见API的运用, 咱们还应探索多线程的底层, 避免只见树木不见森林.
  • 机缘巧合, 有幸学习了Casa的PThread课程, 针对GCD的底层PThread, Casa在这两个多小时的课程中有着深入浅出的讲解. 帮助广大开发者既见树木又见森林. Casa博客PThread介绍
  • 假如你对iOS中多线程的底层技术PThread也有所好奇, 无妨和我一同跟着Casa的思路看下去:)
  • ps: 文章纯手打, 如有错误, 请评论区纠正, 在此谢过了~

章节1 线程基础概念和操作

1.1. POSIX和多线程

  • POSIX Thread

  • 各种各样的操作体系, 他们接口不统一, 所以需求针对每一种操作体系写不同的代码

  • 很费事, 怎么办?

  • Portable Operating System Interface 可移植操作体系接口

  • POSIX规范中的Thread章节(2.9 Threads)

  • 界说的函数都是pthread最初的

  • 大部分主流体系都不是严格恪守POSIX

  • POSIX具备指导意义, 实际状况还是要看操作体系对应文档

1.2. 线程的创立

  • 如何创立一个线程?

  • 猜一下 线程 = 创立线程(要做的作业, 作业的参数, 线程的装备, 存储线程的结构体)

  • 成果? pthread_create(线程记载, 线程特点, 作业, 参数)

int pthread_create(pthread_t *thread, const pthread_attr_t *attr,
void*(*start_routine)(void *), void *arg)

1.3. 线程的特点和Join/Detach

  • stack

  • sechedule

    • 走体系默许
    • 交给体系

  • 杂项

    • detach state 
      • joinalbe(默许)/detached 
      • 有人等/无所谓 
    • scope
      • 线程竞赛时, 参加竞赛的规模
      • 即优先级有规模
      • process(默许)/system

  • Detach vc Join

    • 一个detach特点的线程
      • 意味着你拿不到这个线程的返回值(假如有的话)
      • 而且, 在这个线程完毕之后, 相关资源就会被马上收回.
    • 一个join特点的线程
      • 在线程完毕之后资源不会被马上开释, 而是等候其他线程来join
      • 当把自己的返回值交给来join的线程之后, 自己就会被开释
      • 假如一向没有线程来join, 那这个线程就会一向存在, 直到进程完毕.

  • Detach

    • -> 创立线程 -> 持续履行
    • Detach特点的子线程 ->
    • 使命完毕体系马上收回

  • Join(接应)

    • int pthread_join(pthread_t thread, void **retval)
    • 存储子线程使命成果
    • -> 创立线程 -> 调用pthread_join并等候指定线程 等候中 pthread_join的等候完毕 -> 持续履行
    • join特点的子线程 -> 使命完毕 ^ 传递使命成果

  • 很多个线程一同Join一个子线程?

    • 子线程只能被join 1次!
    • 先到先得!
    • 创富join一个线程无任何作用

1.4. 线程的完毕

  • join

    • pthread_join(pthread_t thread, void **value_ptr)
    • 父线程监听子线程的完毕, 并经过pthread_join函数取得子线程的返回值

  • exit

    • pthread_exit(void **value_ptr)
    • 子线程自动完毕, 经过pthread_exit传递值给父线程的pthread_join去接收

  • kill

    • pthread_kill(pthread_t thread, int sig)
    • 向 [子线程/自己] 发送指定的信号, 假如子线程没有呼应该信号的代码,
    • 则交由进程呼应. 例如发送SIGQUIT信号, 子线程不呼应的话,
    • 进程就会呼应该信号, 完毕进程

  • return

    • 本质上跟pthread_exit一样, 但是不会调用cleanup函数
    • cleanup函数, 清理函数
      • pthread_cleanup_push
      • pthread_cleanup_pop
      • 要一一对应, 否则编译不过

1.5. 撤销一个线程

  • pthread_cancel撤销一个线程

  • int pthread_cancel(pthread_t threas)

  • 调用pthread_cancel能够让对应线程运转到撤销点时撤销线程

  • 线程撤销点?

    • POSIX规范, 
    • 表里的函数都是线程撤销点
    • 纷歧定准!不是一切的规范都去恪守, 看操作体系

  • 有些C库没有符合POSIX规范, 所以在调用这些函数之前,能够自建线程撤销点

  • void pthread_testcancel(void), 告知CPU检查状况, 是否被撤销

1.6. POSIX里其他有用的函数

  • pthread_once

    • pthread_once(pthread_once_t *once_control, void (routine)(void))
    • 运用PTHREAD_ONCE_INIT去初始化once_control

  • pthread_self & phtread_equal

      • pthread_t pthread_self() 
      • 告知你自己是谁
      • int pthread_equal(pthread_t thread1, pthread_t thread2)
      • 告知你跟你一样的人是谁

章节2 锁和各种状况

2.7. Mutex锁

  • 能够衍生出递归锁同享锁

  • 锁是干什么用的?

    • 一条线程给count加1
    • 期望的count成果是2
      1. 从内存读取变量的值
      1. 在读到的值上+1
      1. 将成果写回内存

  • 两条线程给count加1, 期望的count成果是3

    • 多条线程同享同一块内存
      1. 从内存读取变量的值 count 1 count 1
      1. 在读到的值上+1 count 2 count 2
      1. 将成果写回内存 count 2 count 2

  • 怎么办?

    • 临界区的概念
    • 不期望一个线程在履行使命的时分, 其他线程掺和进来
    • 这段使命叫临界区, 一个使命只能有一个线程履行

  • 问题原因?

    • 临界区被多个线程一起操作了

  • 经过加锁使得临界区只需一个线程在履行

  • 加锁的状况

    • 请求锁
    • 从内存读取变量的值
    • 在读到的值上+1
    • 将成果写回内存
    • 开释锁
    • 此刻绿色线程能够成功读取内存中变量的值

  • Mutex Lock 最常用的锁, 相关的5个函数

    • int pthread_mutex_init(pthread_mutex_t *mutex, const pthread_mutexattr_t *attr)
    • int pthread_mutex_destroy(pthread_mutex_t *mutex)
    • int pthread_mutex_lock(pthread_mutex_t *mutex)
    • int pthread_mutex_unlock(pthread_mutex_t *mutex)
    • int pthread_mutex_trylock(pthread_mutex_t *mutex) 不用让线程一向处于等候状况

2.8. Mutex锁的各种特点

  • Mutex锁的特点

    • priority ceiling
      • 数字 避免优先级回转 当前线程优先级
    • mutex protocol
      • INHERIT/ NONE(默许) / PROTECTED 避免优先级回转 
    • process shared
      • PRIVATE(默许)
      • SHARED
      • 是否能够跟其它线程同享锁, 哪怕是跨进程
    • mutex type 
      • NORMAL 不记载持有人
      • DEFAULT(默许) 保留名
      • ERRORCHECK 不能重复加锁解锁
      • RECURSIVE 允许同一线程加N次锁, 但也要解锁N次才会开释
    • robust
      • STALLED(默许) / ROBUST
      • 假如没解锁线程就跪了: 啥也不做 / 让下一个线程处理

2.9. 优先级回转及处理方案

  • 优先级回转?

    • 低优先级的线程反而优先于高优先级的线程履行

  • 正常的状况

    • 低优先级线程 R -> 开释资源
    • 高优先级线程 -> R被占用 告诉低优先级的线程我要抢占你了

  • 优先级回转的场景

    • R -> 开释资源 被中优先级的线程抢占了, 体系让中优先级的线程先履行
    • -> R          中优先级的使命完毕, 低优先级的才干持续履行
    • 中优先级的线程打断了低优先级线程的开释流程
    • 使得中优先级线程反而先于高优先级的线程履行

  • 怎么办?

    • 不应该让中优先级的线程去打断低优先级线程的资源收回流程
    • 开释资源的时分(关键临界区)不允许被中断
    • 无锁同步方案(Non-blocking Synchronization / Read-Copy-Update)
    • Priority Ceiling Protocol
      • 是Mutex锁的一个特点
      • 装备了该特点之后, 其实便是装备了优先级
      • 低优先级 1 中优先级 5 高优先级 8
      • 开释资源(ceiling更高的才干抢占)
      • 中优先级的线程无法抢占低优先级的线程了
      • 由于priority没有ceiling高
    • Priority Inheritance
      • 中优先级的线程无法抢占低优先级线程了
      • 由于priority没有红色线程高
      • 低优先级inherit(继承)自高优先级, 中优先级的不会比高优先级线程高

2.10. 跨进程同享锁

  • process shared

  • 让锁能够被跨进程同享

  • 看看多进程, fork函数创立进程


fork()
PID = 0  PID > 0

  • 进程同享锁

    • 经过进程的同享内存, 进行锁的同享

int shmid = shmget(1616, sizeof(TShared), IPC_CREAT|0666);
TShared *shm = (Tshared *)shmat(shmid, NULL,0);
pthread_mutex_init(&shm->Lock, 带上pshared特点);

  • 进程同享锁和同享锁是什么区别?

    • 绝大多数场景是用在读写锁的读锁里边
    • 很少用
    • 调度的单位往往是线程
    • 涉及到进程同享, 简单犯错, 尽量少用

2.11. 递归锁

  • mutex type 

    • NORMAL 不记载持有人, 重复加锁, 无休止等候, 死锁
    • DEFAULT 保留名
    • ERRORCHECK 不能重复加锁解锁, 会报错
    • RECURSIVE 允许同一线程加N次锁, 但也要解锁N次才会开释, 会报成功

void foo() {
... 请求锁();
...foo();
...开释锁();
}
  • 不会被自己锁住, 即使递归调用也能正常请求到锁

2.12. 锁的Robust机制

  • robust 使健壮

    • STALLED(默许) / ROBUST
    • 假如没解锁线程就跪了;
    • 啥也不做 / 让下个线程处理

  • 当持有一个锁的线程还没开释就挂了, 会发生什么?

    • STALLED 
      • 无法请求到锁, 未界说的行为. 
      • 后边请求这个锁的线程或许会一向wait
    • ROBUST
      • 下一个请求这个锁的线程会收到一个 EOWNERDEAD 错误
      • 第三个第四个请求锁的线程会处于waiting状况
      • 这个线程能够尝试康复上一个线程挂掉之后对锁或对程序履行逻辑的影响
      • 假如康复成功, 就能够调用pthread_mutex_consistent()函数来标记这个锁现已康复正常
      • 然后这个锁就相当于被这个线程给持有了
      • 当这个线程开释锁了之后, 其他后边的线程就能够正常运用锁了
      • 假如康复失败, 这个锁就会永久处于不可用的状况, 只能经过pthread_mutex_destroy()来收回这个锁
    • Robust作业原理
      • 履行一些康复逻辑
      • pthread_mutex_consistent() -> 开释锁

2.13. 在不同场景下一个线程重复加解锁

  • 重复加解锁会怎么样?

    • mutex type
    • robust
    • 同一个线程重复加解锁

  • type       robust   重复加锁(自己给自己加锁) 重复解锁(自己给自己解锁)

  • NORMAL     STALLED  死锁                      未界说行为

  • NORAML     ROBUST   死锁                      报错

  • ERRORCHECK 恣意值   返回错误                  报错

  • RECURSIVE  恣意值   重复加锁                  报错

  • DEFAULT    STALLED  未界说行为                未界说行为

  • DEFAULT    ROBUST   未界说行为                报错

2.14. 死锁

  • 相互锁死便是死锁

  • 单线程或许死锁吗? 或许, 自己重复加锁

  • 主要是多线程下的死锁

  • 怎么办?

    • 按照次序去加锁
    • 第一个线程完结自己的使命后, 第二个线程才干请求到资源

2.15. 读写锁

  • 处理读多写少的问题

  • 期望避免在临界区履行的时分, 其他线程进入到临界区发生干扰

  • 假如其他线程进来是为了读取数据, 进入临界区, 不做坏事

  • 请求写锁, 

  • 请求读锁, 

  • 依据线程的行为来请求读写锁, 提高多线程的性能

  • 读写锁

    • 专治读得太多, 写得太少
    • 创立和毁掉 pthread_rwlock_init & phtread_rwlock_destroy
    • 读锁 phtread_rwlock_rdlock & pthread_rwlock_tryrdlock
    • 写锁 pthread_rwlock_wrlock & pthread_rwlock_trywrlock
    • 解锁 pthread_rwlock_unlock

  • 读写锁的2个特点

    • PShared 是否进程间同享
    • Kind (避免写饥饿)
      • Prefer Reader 读优先, 默许值
        • 写饥饿, 当读优先的时分, 写线程必须要等候前面的读线程都履行完毕了, 才干得到履行
        • 读锁是同享出去的, 多个线程运用
      • Prefer Writer Non-Recursive 写优先
        • 只需请求写锁时, 后边请求读锁就不让进来了 
      • Prefer Writer 同上, glibc中只提供PWNR, 添加这个只是为了跟POSIX对齐

章节3 多线程下的各种机制

3.16. Thread Specific Data – TSD

  • TSD是干什么的?

    • 内存中的数据, 在线程间是被同享的, 
    • 假如想有一个数据, 只能被本线程内一切函数拜访
    • 不能被其他线程拜访, 应该怎么办?
    • 界说的数据是在栈上开辟的, 只能自己拜访.
    • 界说的数据是在堆上开辟的, 一切线程都能拜访, 怎么办? TSD!

  • Thread-specific Data API列表

    • 创立 int pthread_key_create(pthread_key_t *key, void (*destructor)(void *))
    • 删去 int pthread_key_delete(pthread_key_t key)
    • 写入 int pthread_setspecific(pthread_key_t key, const void *value)
    • 读取 void * pthread_getspecific(pthread_key_t key)

  • 不同的线程拿到同一个key, 拿到的也是自己保护的数据, 不同线程能够共用key

  • TSD还是比较慢的, 尽量少用!

3.17. Condition Variables 条件变量

  • 一种线程同步的方法, 线程进入临界区前, 等候信号

  • 比如

      1. 你自己看一下, 只需房间没人, 你就能够进
      • 进卫生间, 加锁, 
      1. 不论房间是不是有人, 别人叫你进了, 你才干进.
      • 进工作室, 也能够用加锁的方法完结, 但有一个问题
      • 假如工作室从一开始就没人, 工作室里没有任何作业人员
      • 加锁的方法处理这个问题, 关键的点是, 之前工作室里必须要有人
      • 假定加锁的线程, 晚于临界区, 无法进入等候状况
      • => Condition Variables! 条件信号, 有或许是迟来的
      • 条件变量的界说, 收到信号, 工作室来人了发信号
      • 锁是先取得锁的线程能够让其他线程等候
      • 条件变量, 先等候信号, 再进入临界区
      • 进入临界区的先后次序不同.

  • Condition Variables

    • 设置条件让其他线程等候, 经过条件变量让其他线程持续运转
    • int pthread_cond_init(pthread_cond_t *cond, const pthread_condattr_t *attr)
    • int pthread_cond_destroy(pthread_cond_t *cond)
    • int pthread_cond_signal(pthread_cond_t *cond) 只会有一个人进入临界区
    • int pthread_cond_broadcast(pthread_cond_t *cond)
      • 广播信号, 一切等候的人都会收到信号
      • 收到信号都会进入临界区
    • int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)

  • Condition Variable的2个特点

    • process shared 
      • shared / private(默许)
      • 条件变量是否能够跨进程?
      • 需求跟mutex的process share特点相配合
    • clock
      • int值; 各种宏, 但只能用: CLOCK_REALTIME(默许)/CLOCK_MONOTONIC(不受体系时间影响)
      • 操控超时时钟, 用于条件变量的timewait函数
    • 一般都是走默许

3.18. 运用条件变量要留意的点

  • 必定要跟mutext一同用

  • 不跟mutext一同用的状况

    • Condition Variable的空等现象 1

void thread_conciton_1() {
done = 1;
pthread_cond_signal(&condition_variable_signal)l
}
void thread_function_w() {
while (done == 0) {
// 或许会引入bug的地方, fuc1马上跑完了, 信号现已扔出去过了
pthread_cond_wait(&condition_variable_signal, NULL);
}
}

  • Condition Variable的空等现象 2

    • 没有先进行条件检测, 再等候条件 (留意while和if的选择)
    • fuc1的信号或许现已宣布过了
    • 必定要在临界区扔出条件变量
      • Condition Variable的数据保护
      • 要在临界区开释mutex锁
      • 流程图
        • 其他线程乘虚而入的时机
        • 临界区 -> 扔信号 -> 唤醒其他线程
        • 临界区里边扔信号 唤醒其他线程

  • 条件变量Condition Variable三大留意

      1. 必定要结合Mutex运用, 空等
      1. 必定要先进行条件检测, 空等
      1. 必定要在临界区扔信号, bug

  • 在Mutex里边去做信号的监听

    • 监听信号时, 信号没有到, 此刻线程会被挂起
    • 前面请求的Mutex就会被开释出来, 其他的条件变量线程就会能够取得这个锁

3.19. Semaphore信号量

  • 条件变量不能操控数量, 信号量能够操控数量

  • 假如一个景区一起只能固定数量的人观赏, 应该怎么办?

    • 锁也能够做, 5个人5把锁, 但是这样做很费事
    • 条件变量, count计数, 判断, 此刻count是49一起有10个人检查, 进入59人
    • 针对count要有个锁, 完结费事
    • => Semaphore! 
    • 一台电脑只联接了3个打印机
      • Semaphore去完结会更优雅
      • 操作体系会提供相应完结

  • Semaphore相关API

    • 不同操作体系
      • int sem_init(sem_t *sem, int pshared, unsigned int value)
      • int sem_open(const char *name, int oflag, ...)
    • int sem_post(sem_t *sem) // value 加1
    • int sem_wait(sem_t *sem) // value 减1
    • int sem_destroy(sem_t *sem) // 开释信号量
    • int sem_getvalue(sem_t *sem, int *sval) // 取得信号量当前的值

  • Semaphore运用: 值 > 0、post +1、wait -1

  • 出产者消费者代码

    • 出产者每出产完一个产品post +1
    • 消费者每消费一个产品wait -1
    • 用完destroy
    • 创立毁掉+1-1

3.20. Barrier多线程栅门函数

  • 等其他线程都到某个点后, 我再持续

    • 建一个房子, 三件事前预备, 找三个辅佐一起办三件作业
    • 三个作业都完结, 才干开始后边的作业
    • 先完结手上的作业后, 才干进行下一步
    • => Barrier!

  • Barrier相关API

    • 设立一个栅门, 让相关的线程走到预订位置就wait, 一切人都走了, 再持续.
    • int pthread_barrier_init(pthread_barrier_t *barrier, const pthread_barrierattr_t *attr, unsigned int count)
    • int pthread_barrier_destroy(pthread_barrier_t *barrier)
    • `int pthread_barrier_wait(pthread_barrier_t *barrier) 只需凑够一开始创立的线程的数量, 就能到达目的

  • Barrier只需1个特点

    • Process-shared
    • 可选项 private(默许) / shared
    • 作用 是否能够进行跨进程同享

  • Barrier到底是个啥?

    • 处理了什么问题?
    • 三个线程不知道什么时分开始, 什么时分完毕
    • 需求在某个时间, 三个线程需求一起触发
    • 第一个线程完结使命 -> 栅门点, 等候
    • 第二个线程完结使命 -> 栅门点, 等候
    • 第三个线程完结使命 -> 栅门点, 等候
    • 一切的线程都到达了栅门点 => 一切的线程能够持续了

  • 天选之子机制

    • wait函数返回的值是一个宏界说
    • 其他的线程返回的是0
    • 一切wait的线程唤醒之后
    • 只需一个线程收到的返回值是PTHREAD_BARRIER_SERIAL_THREAD
    • 其它线程收到的返回值是0
    • int result = phterad_barrier_wait(&mybarrier);

  • 天选之子能够干什么用?

    • 多线程归并排序, 
    • 需求一个唯一的线程做成果的归并

课程学习导图

  • Casa的PThread公开课传送门🚪
    Casa的PThread (1).png

发文不易, 喜爱点赞的人更有好运气👍 :), 定期更新+关注不迷路~

ps：欢迎参加笔者18年树立的研究iOS审核及前沿技术的三千人扣群：662339934，坑位有限，补白“网友”可被群管经过~