【Linux】线程互斥
目录
1 进程线程间的互斥相关背景概念
2 互斥量mutex
3 互斥量的接口
4 加锁细节
5 互斥量实现原理探究
6 thread封装
7 mutex的封装
8 重入和线程安全
8.1 相关概念
8.2 常见线程不安全的情况
8.3 常见线程安全的情况
8.4 常见的不可重入的情况
8.5 常见的可重入的情况
8.6 可重入与线程安全联系
8.7 可重入与线程安全区别
9 常见锁概念
死锁
死锁四个必要条件
避免死锁
1 进程线程间的互斥相关背景概念
- 临界资源：多线程执行流共享的资源就叫做临界资源 -- 衡量资源的
- 临界区：每个线程内部，访问临界资源的代码，就叫做临界区 -- 衡量代码的
- 互斥：任何时刻，互斥保证有且只有一个执行流进入临界区，访问临界资源，通常对临界资源起保护作用
- 原子性：不会被任何调度机制打断的操作，该操作只有两态，要么完成，要么未完成
2 互斥量mutex
- 大部分情况，线程使用的数据都是局部变量，变量的地址空间在线程栈空间内，这种情况，变量归属单个线程，其他线程无法获得这种变量。
- 但有时候，很多变量都需要在线程间共享，这样的变量称为共享变量，可以通过数据的共享，完成线程之间的交互。
- 多个线程并发的操作共享变量，会带来一些问题。
【代码举例】
模拟用户（一个线程一个用户）抢票问题
#include
#include
using namespace std;
#include
#include
int tickets = 1000; // 表示有这么多票
void *threadRoutine(void *args)
{
string name = static_cast(args);
while (true)
{
if (tickets > 0) // 表示有票
{
usleep(200); // 开始抢票前的工作
cout << name << " get a ticket:" << tickets-- << endl;
}
else
{
break;
}
}
}
int main()
{
pthread_t t[4]; // 四个线程模拟四个用户
int n = sizeof(t) / sizeof(t[0]);
for (int i = 0; i < n; ++i)
{
char *name = new char[64];
snprintf(name, 64, "thread:%d ", i + 1);
pthread_create(t + i, nullptr, threadRoutine, (void *)name);
}
for (int i = 0; i < n; ++i)
{
pthread_join(t[i], nullptr);
}
return 0;
} 
提出问题：为什么出现了抢到票的编号为-1？也就是，没有票了为什么用户还能再继续抢票？
- if 语句判断条件为真以后，代码可以并发的切换到其他线程
- usleep 这个模拟漫长业务的过程，在这个漫长的业务过程中，可能有很多个线程会进入该代码段
- --ticket 操作本身就不是一个原子操作
-- 操作并不是原子操作，而是对应三条汇编指令：
- load ：将共享变量ticket从内存加载到寄存器中
- update : 更新寄存器里面的值，执行-1操作
- store ：将新值，从寄存器写回共享变量ticket的内存地址
要解决以上问题，需要做到三点：
- 代码必须要有互斥行为：当代码进入临界区执行时，不允许其他线程进入该临界区。
- 如果多个线程同时要求执行临界区的代码，并且临界区没有线程在执行，那么只能允许一个线程进入该临界区。
- 如果线程不在临界区中执行，那么该线程不能阻止其他线程进入临界区。
要做到这三点，本质上就是需要一把锁。Linux上提供的这把锁叫互斥量。
3 互斥量的接口
初始化互斥量
初始化互斥量有两种方法：
- 方法1，静态分配:
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER
- 方法2，动态分配:
int pthread_mutex_init(pthread_mutex_t *restrict mutex, const pthread_mutexattr_t *restrict
attr);
参数：
mutex：要初始化的互斥量
attr：NULL
销毁互斥量
销毁互斥量需要注意：
- 使用 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调用会陷入阻塞(执行流被挂起)，等待互斥量解锁。
【改进抢票系统】
int tickets = 1000; // 表示有这么多票
pthread_mutex_t mutex=PTHREAD_MUTEX_INITIALIZER;
void *threadRoutine(void *args)
{
string name = static_cast(args);
while (true)
{
int ret=pthread_mutex_lock(&mutex);
assert(ret==0);
(void)ret;
if (tickets > 0) // 表示有票
{
usleep(200); // 开始抢票前的工作
cout << name << " get a ticket:" << tickets-- << endl;
ret=pthread_mutex_unlock(&mutex);
assert(ret==0);
}
else
{
ret=pthread_mutex_unlock(&mutex);
assert(ret==0);
break;
}
usleep(100);
}
}
int main()
{
//pthread_mutex_init(&mutex,nullptr);
pthread_t t[4]; // 四个线程模拟四个用户
int n = sizeof(t) / sizeof(t[0]);
for (int i = 0; i < n; ++i)
{
char *name = new char[64];
snprintf(name, 64, "thread:%d ", i + 1);
pthread_create(t + i, nullptr, threadRoutine, (void *)name);
}
for (int i = 0; i < n; ++i)
{
pthread_join(t[i], nullptr);
}
//pthread_mutex_destroy(&mutex);
return 0;
} 
这样就能确保抢票的准确性！
4 加锁细节
- 凡是访问同一个临界资源的线程，都要进行加锁保护，而且必须加同一把锁，这个是一个游戏规则，不能有例外；
- 每一个线程访问临界区之前，得加锁，加锁本质是给临界区加锁，加锁的粒度尽量要细一些，减少串行代码；
- 线程访问临界区的时候，需要先加锁->所有线程都必须先看到同一把锁->锁如何保证自己的安全？-> 加锁和解锁本身就是原子的！
- 临界区可以是一行代码，可以是一批代码
- 加锁后，线程可能被切换吗？当然可能，不要特殊化加锁和解锁，还有临界区代码。
- 切换线程之后会有影响吗？不会，因为我不在期间，任何人都没有办法进入临界区，因为他无法成功的申请到锁！因为锁被我拿走了！
- 这也正是体现互斥带来的串行化的表现，站在其他线程的角度，对其他线程有意义的状态是：锁被我申请（持有锁），锁被我释放了（不持有锁），原子性就体现在这里；
- 解锁的过程也是被设计成原子的！
5 互斥量实现原理探究
- 经过上面的例子，大家已经意识到单纯的 i++ 或者 ++i 都不是原子的，有可能会有数据一致性问题
- 为了实现互斥锁操作,大多数体系结构都提供了swap或exchange指令,该指令的作用是把寄存器和内存单元的数据相交换,由于只有一条指令,保证了原子性,即使是多处理器平台,访问内存的 总线周期也有先后,一个处理器上的交换指令执行时另一个处理器的交换指令只能等待总线周期。 现在我们把lock和unlock的伪代码改一下
6 thread封装
#pragma once
#include
#include
#include
#include
class thread
{
public:
typedef enum
{
NEW=0,
RUN,
EXIT
}ThreadStatus;
public:
thread(int num,std::function func_t,void* args)
:_func_t(func_t)
,_id(0)
,_args(args)
,_status(NEW)
{
char buffer[64];
snprintf(buffer,sizeof(buffer),"thread:%d ",num);
std::string name=buffer;
_name=move(name);
}
static void* runHelp(void* args)
{
thread* t=static_cast(args);
(*t)();
return nullptr;
}
void operator()()
{
if(_func_t!=nullptr)_func_t(_args);;
}
void run()
{
int ret=pthread_create(&_id,nullptr,runHelp,this);
if(ret!=0)
{
cout<<"create error"< _func_t;
std::string _name;
pthread_t _id;
void* _args;
ThreadStatus _status;
}; 7 mutex的封装
#pragma once
#include
class Mutex
{
public:
Mutex(pthread_mutex_t* mutex):_pmutex(mutex)
{}
void lock()
{
pthread_mutex_lock(_pmutex);
}
void umlock()
{
pthread_mutex_unlock(_pmutex);
}
private:
pthread_mutex_t* _pmutex;
};
class LockGuard
{
public:
LockGuard(pthread_mutex_t* mutex):_mutex(mutex)
{
_mutex.lock();
}
~LockGuard()
{
_mutex.umlock();
}
private:
Mutex _mutex;
};
8 重入和线程安全
8.1 相关概念
- 线程安全：多个线程并发同一段代码时，不会出现不同的结果。常见对全局变量或者静态变量进行操作，并且没有锁保护的情况下，会出现该问题。
- 同一个函数被不同的执行流调用，当前一个流程还没有执行完，就有其他的执行流再次进入，我们称之为重入。一个函数在重入的情况下，运行结果不会出现任何不同或者任何问题，则该函数被称为可重入函数，否则，是不可重入函数。
8.2 常见线程不安全的情况
- 不保护共享变量的函数
- 函数状态随着被调用，状态发生变化的函数
- 返回指向静态变量指针的函数
- 调用线程不安全函数的函数
8.3 常见线程安全的情况
- 每个线程对全局变量或者静态变量只有读取的权限，而没有写入的权限，一般来说这些线程是安全的
- 类或者接口对于线程来说都是原子操作
- 多个线程之间的切换不会导致该接口的执行结果存在二义性
8.4 常见的不可重入的情况
- 调用了malloc/free函数，因为malloc函数是用全局链表来管理堆的
- 调用了标准I/O库函数，标准I/O库的很多实现都以不可重入的方式使用全局数据结构
- 可重入函数体内使用了静态的数据结构
8.5 常见的可重入的情况
- 不使用全局变量或静态变量
- 不使用用malloc或者new开辟出的空间
- 不调用不可重入函数
- 不返回静态或全局数据，所有数据都有函数的调用者提供
- 使用本地数据，或者通过制作全局数据的本地拷贝来保护全局数据
8.6 可重入与线程安全联系
- 函数是可重入的，那就是线程安全的
- 函数是不可重入的，那就不能由多个线程使用，有可能引发线程安全问题
- 如果一个函数中有全局变量，那么这个函数既不是线程安全也不是可重入的。
8.7 可重入与线程安全区别
- 可重入函数是线程安全函数的一种
- 线程安全不一定是可重入的，而可重入函数则一定是线程安全的。
- 如果将对临界资源的访问加上锁，则这个函数是线程安全的，但如果这个重入函数若锁还未释放则会产生死锁，因此是不可重入的。
- 可重入是函数的一种特性，没有好不好的问题；线程安全是一个程序的安全问题，存在好不好的问题。
9 常见锁概念
死锁
概念：死锁是指在一组进程中的各个进程均占有不会释放的资源，但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态。（可能由一个或者多个锁导致死锁）
死锁四个必要条件
- 互斥条件：一个资源每次只能被一个执行流使用
- 请求与保持条件：一个执行流因请求资源而阻塞时，对已获得的资源保持不放
- 不剥夺条件:一个执行流已获得的资源，在末使用完之前，不能强行剥夺
- 循环等待条件:若干执行流之间形成一种头尾相接的循环等待资源的关系
避免死锁
- 破坏死锁的四个必要条件
- 加锁顺序一致
- 避免锁未释放的场景
- 资源一次性分配
