文章目录
- 线程互斥
线程互斥
互斥量mutex
- 大部分情况,线程使用的数据都是局部变量,变量的地址空间在线程栈空间内,这种情况,变量归属单个线程,其他线程无法获得这种变量。
- 但有时候,很多变量都需要在线程间共享,这样的变量称为共享变量,可以通过数据的共享,完成线程之间的交互。
- 多个线程并发的操作共享变量,会带来一些问题
比如我们之前的抢票代码最后结果不符合我们的预期。
代码:
#include <iostream>
#include <thread>
#include <pthread.h>
#include <unistd.h>
#include <cstdio>
#include <cerrno>
#include <cstring>int tickets = 10000;
void *GetTickets(void *args)
{while (true){if (tickets > 0){usleep(1000);printf("%p : %d\n", pthread_self(), tickets);tickets--;}else{break;}}return nullptr;
}int main()
{pthread_t t1;pthread_t t2;pthread_t t3;pthread_create(&t1, nullptr, GetTickets, nullptr);pthread_create(&t2, nullptr, GetTickets, nullptr);pthread_create(&t3, nullptr, GetTickets, nullptr);pthread_join(t1, nullptr);pthread_join(t2, nullptr);pthread_join(t3, nullptr);return 0;
}
运行结果:
我们抢票抢到1张就应该结束结束了,但是上面抢到了-1所以代码肯定有问题
那么为什么会出现问题呢?
为什么可能无法获得争取结果?
- if 语句判断条件为真以后,代码可以并发的切换到其他线程
- usleep这个模拟漫长业务的过程,在这个漫长的业务过程中,可能有很多个线程会进入该代码段
- ticket- -操作本身就不是一个原子操作
1.判断的本质也是计算的一种
2.抢票的时候tickets–可能出现问题。
深究问题
tickets计算的步骤:
1.读取数据到CPU寄存器中
2.CPU内部进行tickets–
3.将结果写回内存
比如有两个线程t1和t2
首先线程t1对tickets进行–操作,但是t1在执行第三步的时候被切换了
然后CPU调度线程t2来进行抢票,但是t2一直把票抢到只剩5000才被切换
这时候t1又被调度上来了,而t1的上下文记得t1正在执行第三步的时候被切换,所以t1从第三步开始执行。
这时候就出错了。
那么怎么避免这样问题的产生?加锁保护
要解决以上问题,需要做到三点:
代码必须要有互斥行为
:当代码进入临界区执行时,不允许其他线程进入该临界区。- 如果多个线程同时要求执行临界区的代码,并且临界区没有线程在执行,那么
只能允许一个线程进入该临界区
。 - 如果线程不在临界区中执行,那么该线程不能阻止其他线程进入临界区。
要做到这三点,本质上就是需要一把锁。Linux上提供的这把锁叫互斥量。
pthread_mutex_
t就是原生线程库提供的一种数据类型
如果锁是全局的,那么可以用PTHREAD_MUTEX_INITIALIZER对其进行初始化
销毁互斥量
销毁互斥量需要注意:
使用PTHREAD_ MUTEX_ INITIALIZER初始化的互斥量不需要销毁
不要销毁一个已经加锁的互斥量
已经销毁的互斥量,要确保后面不会有线程再尝试加锁
int pthread_mutex_destroy(pthread_mutex_t *mutex);
互斥量加锁和解锁
int pthread_mutex_lock(pthread_mutex_t *mutex);
int pthread_mutex_unlock(pthread_mutex_t *mutex);
//返回值:成功返回0,失败返回错误号
调用pthread_ lock 时,可能会遇到以下情况:
- 互斥量处于未锁状态,该函数会将互斥量锁定,同时返回成功
- 发起函数调用时,其他线程已经锁定互斥量,或者存在其他线程同时申请互斥量,但没有竞争到互斥量,那么pthread_lock调用会陷入阻塞(执行流被挂起),等待互斥量解锁。
更改代码为线程安全的:
全局锁(静态分配)
#include <iostream>
#include <thread>
#include <pthread.h>
#include <unistd.h>
#include <cstdio>
#include <cerrno>
#include <cstring>pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER;int tickets = 10000;
void *GetTickets(void *args)
{while (true){pthread_mutex_lock(&mtx);if (tickets > 0){usleep(1000);printf("%p : %d\n", pthread_self(), tickets);tickets--;pthread_mutex_unlock(&mtx);}else{pthread_mutex_unlock(&mtx);break;}}return nullptr;
}int main()
{pthread_t t1;pthread_t t2;pthread_t t3;pthread_create(&t1, nullptr, GetTickets, nullptr);pthread_create(&t2, nullptr, GetTickets, nullptr);pthread_create(&t3, nullptr, GetTickets, nullptr);pthread_join(t1, nullptr);pthread_join(t2, nullptr);pthread_join(t3, nullptr);return 0;
}
运行结果:
加锁保护区间的代码称为临界区,tickets称为临界资源
而加锁保护一定带来了效率的降低,加锁的时候一定要保证加锁的粒度越小越好。
局部锁(动态分配)
:
#include <iostream>
#include <thread>
#include <pthread.h>
#include <unistd.h>
#include <cstdio>
#include <cerrno>
#include <cstring>#define NUM 5struct ThreadData
{
public:ThreadData(std::string name, pthread_mutex_t *mtx): _name(name),_mtx(mtx){}public:std::string _name;pthread_mutex_t *_mtx;
};int tickets = 10000;
void *GetTickets(void *args)
{ThreadData *td = (ThreadData *)args;while (true){int n = pthread_mutex_lock(td->_mtx);assert(n == 0);if (tickets > 0){usleep(1000);printf("%s : %d\n", td->_name.c_str(), tickets);tickets--;n = pthread_mutex_unlock(td->_mtx);assert(n == 0);}else{n = pthread_mutex_unlock(td->_mtx);assert(n == 0);break;}}return nullptr;
}int main()
{pthread_mutex_t mtx;pthread_mutex_init(&mtx, nullptr);pthread_t t[NUM];for (int i = 0; i < NUM; i++){std::string name = "Thread";name += std::to_string(i+1);ThreadData *td = new ThreadData(name, &mtx);pthread_create(t + i, nullptr, GetTickets, (void *)td);}for (int i = 0; i < NUM; i++){pthread_join(*(t + i), nullptr);}pthread_mutex_destroy(&mtx);return 0;
}
运行结果:
加锁之后,线程在临界区中,是否会切换,会有问题吗?
原子性的体现
线程在临界区中会被切换,但是不会有问题,虽然被切换了,但是是持有锁被切换的,因为其它抢票线程要执行临界区代码,必须申请锁,但是锁被申请了,所以其它线程锁是不会申请成功的,那么其它线程也不会进入临界区,这样就保证了临界区中数据的一致性。
假如一个线程不申请锁,就能访问到临界区资源的话,那么这一定是错误的编码方式。
在没有持有锁的线程看来,对它最有意义的情况有两种:
1.线程1没有持有锁
2.线程1释放锁,此时我就可以申请锁了。
加锁就是多个线程串行执行了吗?
是的,执行临界区代码的时候线程一定是串行的。
要访问临界资源,每一个线程都必须申请锁,每一个线程都必须先看到同意一把锁&&访问它,那么锁本身是不是就是一种临界资源?是!
那么谁来保证锁的安全?
所以为了保证锁的安全,申请和释放锁,必须是原子的!
互斥实现原理的探究
- 经过上面的例子,大家已经意识到单纯的i++或者++i都不是原子的,有可能会有数据一致性问题
- 为了实现互斥锁操作,大多数体系结构都提供了swap或exchange指令,该指令的作用是把寄存器和内存单元的数据相交换,由于只有一条指令,保证了原子性,即使是多处理器平台,访问内存的总线周期也有先后,一个处理器上的交换指令执行时另一个处理器的交换指令只能等待总线周期。 现在我们把lock和unlock的伪代码改一下
swap或者exchange指令,如果我们在汇编的角度,只有一条汇编语句,我们就认为汇编语句的执行是原子的!
swap或者exchange指令以一条汇编的方式,将内存和CPU内寄存器数据进行交换
在执行流视角是如何看待CPU上的寄存器?
CPU内部的寄存器的数据,本质叫做当前执行流的上下文!寄存器的空间是被所有的执行流共享的,但是寄出器内部的内容是被每一个执行流私有的称之为上下文!
申请锁的过程。
假设有一个线程A,正在申请锁
但是刚执行第一步就被切换走了
第一步:
然后被切走,线程A就保存好自己的上下文明。
线程B刚好被调度,又申请锁
但是线程B没有被切换,执行3完了申请锁的过程
而这时候线程B被切换就带走自己的上下文。
接下来线程A又被调度,在寄存器恢复自己的上下文
然后开始向后执行
但是交换后,代码继续向后执行发现是0,就挂起等待。
接下来就切换其它线程进行调度。
所以谁来保证锁的安全?锁自己保证!
可重入函数VS线程安全:
线程安全:多个线程并发同一段代码时,不会出现不同的结果。常见对全局变量或者静态变量进行操作,并且没有锁保护的情况下,会出现该问题。
重入:同一个函数被不同的执行流调用,当前一个流程还没有执行完,就有其他的执行流再次进入,我们称之为重入。一个函数在重入的情况下,运行结果不会出现任何不同或者任何问题,则该函数被称为可重入函数,否则,是不可重入函数。
一个函数是可重入的那么一定就是线程安全的。
常见的线程不安全的情况:
- 不保护共享变量的函数
- 函数状态随着被调用,状态发生变化的函数
- 返回指向静态变量指针的函数
- 调用线程不安全函数的函数
常见的线程安全的情况
- 每个线程对全局变量或者静态变量只有读取的权限,而没有写入的权限,一般来说这些线程是安全的
- 类或者接口对于线程来说都是原子操作
- 多个线程之间的切换不会导致该接口的执行结果存在二义性
常见不可重入的情况
- 调用了malloc/free函数,因为malloc函数是用全局链表来管理堆的
- 调用了标准I/O库函数,标准I/O库的很多实现都以不可重入的方式使用全局数据
- 结构可重入函数体内使用了静态的数据结构
常见可重入的情况
- 不使用全局变量或静态变量
- 不使用用malloc或者new开辟出的空间
- 不调用不可重入函数
- 不返回静态或全局数据,所有数据都有函数的调用者提供
- 使用本地数据,或者通过制作全局数据的本地拷贝来保护全局数据
可重入与线程安全联系
- 函数是可重入的,那就是线程安全的
- 函数是不可重入的,那就不能由多个线程使用,有可能引发线程安全问题 如果一个函数中有全局变量,那么这个函数既不是线程安全也不是可重入的。
可重入与线程安全区别
- 可重入函数是线程安全函数的一种
- 线程安全不一定是可重入的,而可重入函数则一定是线程安全的。
- 如果将对临界资源的访问加上锁,则这个函数是线程安全的,但如果这个重入函数若锁还未释放则会产生死锁,因此是不可重入的。
常见锁概念:
死锁:
而这就造成了死锁的情况,线程A有锁1要锁2,线程B有锁2要锁1,互不相让。
2把或者以上的锁都有可能造成死锁。1把锁也有可能造成死锁问题。
死锁四个必要条件
- 互斥条件:一个资源每次只能被一个执行流使用
- 请求与保持条件:一个执行流因请求资源而阻塞时,对已获得的资源保持不放
- 不剥夺条件:一个执行流已获得的资源,在末使用完之前,不能强行剥夺
- 循环等待条件:若干执行流之间形成一种头尾相接的循环等待资源的关系
避免死锁
- 破坏死锁的四个必要条件
- 加锁顺序一致
- 避免锁未释放的场景
- 资源一次性分配
避免死锁算法
死锁检测算法(了解)
银行家算法(了解)