目录
互斥
为什么需要锁
先看结果:
以下代码是我模拟创建线程抢票,由于不加锁导致票抢到了负数
main.cc:
#include<vector>
#include<iostream>
#include"Thread.hpp"
#include <unistd.h>
int tickets = 10000;
void Ticket()
{
while (true)
{
if(tickets > 0)
{
usleep(1000);
printf("tickets: %d\n",tickets--);
}
else
return ;
}
}
int main()
{
std::vector<xjh::Thread> arr;
for(int i = 0; i < 4; i++)
{
arr.emplace_back(Ticket);
}
for(int i = 0; i < 4; i++)
{
arr[i].Start();
}
for(int i = 0; i < 4; i++)
{
arr[i].Join();
}
return 0;
}
由于我封装了pthread,奉上
Thread.hpp
#include<pthread.h>
#include<functional>
namespace xjh
{
using pfunc = std::function<void()>;
static int i = 0;
class Thread
{
static void* Handle(void* args)
{
Thread* td = static_cast<Thread*>(args);
td->_func();
return nullptr;
}
public:
Thread(pfunc func):_func(func)
{
i++;
}
void Start()
{
pthread_create(&_pid,nullptr,Handle,this);
}
void Join()
{
pthread_join(_pid,nullptr);
}
~Thread()
{}
private:
pfunc _func;
pthread_t _pid;
};
}
造成以上结果的原因就是在
1、if()操作不是原子操作
2、线程的调度切换
原子性:不会被任何调度机制打断的操作,该操作只有两态,要么完成,要么未完成
简单想象一下,比如张三在询问完是否还有余票的时候,有,就进去拿了,如果此时只有一张票了,这个时候李四来了,张三还没有出来,李四说还有一张票,也进去了。这个时候就出错了。
锁的原理--互斥
数据被多次拿到的对策就是一次只允许一个人可以使用这一份资源。
比如单人自习室门口挂了一个令牌,在进入自习室的时候必须带上令牌,并且只有一个人可以进入自习室,这个时候。我们规定好在这个人交出令牌之前其他人不得入内。这个时候这个令牌就是锁了。
那么底层的原理就是有一个东西类似与这个令牌。但是我又怎么保障拿到这个令牌的时候别人不来抢呢?这时候我们就要保证拿令牌这个操作是原子操作了。
如上,在操作系统内部,有swap和exchange来保证原子性,当一个拿到了内存里面mutex的锁的被放到了自己的寄存器里,别人就拿不到只能阻塞等待了
锁的使用
- 锁的本质就是对资源的保护。需要保护的资源是临界资源。
- 因为拿不到锁的线程会阻塞,所以不能大块的代码加锁,要保证细粒度
- 加锁就是找到临界区,对临界区加锁
同步
依旧讲故事理解:
锁的问题
在单人自习室的时候,比如张三在拿到令牌了之后,从早上7点学到了中午12点,张三准备去吃饭了,但是自习室门口排满了队,等待着使用这个单人自习室,张三走到了自习室门口,刚把令牌挂上去。就看到。自习室门一堆的人,想到又是等一下吃完饭再来,又要排很久的队,于是又把令牌拿上进入自习室。由于令牌是张三挂上去的,所以最先拿到令牌的肯定是张三。张三在进入自习室后,肚子依然很饿,于是又把令牌挂上去,但是他又不想排队,又拿上令牌进入自习室,进入自习室肚子又饿也学不好。如此反复,自习室外面的人没有拿到自习室的使用权,而张三又由于肚子饿,也没有利用上这个自习室。
这样就造成了饥饿问题,但是张三有错吗?没错。但是这个策略就有问题
这个时候就要引入条件变量
条件变量
假设自习室门口有一个告示板,上面写着是否允许进入自习室的条件。如果条件不满足(比如自习室满员或者没有空位),学生就在门口等待。当有位置空出时,管理员会在告示板上更新条件,并通知等待的学生。这就是条件变量的基本思想
但是与锁不同的是在这个自习室门口的学生都得排好队,张三出来的时候不能再立马拿令牌,而是要排到队伍后面,这样就解决了饥饿问题。
所以线程排在条件变量的队列里。