目录
互斥
为什么需要锁
锁的原理--互斥
锁的使用
同步
锁的问题
条件变量
互斥
为什么需要锁
先看结果：
以下代码是我模拟创建线程抢票，由于不加锁导致票抢到了负数
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--);}elsereturn ;}
}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点，张三准备去吃饭了，但是自习室门口排满了队，等待着使用这个单人自习室，张三走到了自习室门口，刚把令牌挂上去。就看到。自习室门一堆的人，想到又是等一下吃完饭再来，又要排很久的队，于是又把令牌拿上进入自习室。由于令牌是张三挂上去的，所以最先拿到令牌的肯定是张三。张三在进入自习室后，肚子依然很饿，于是又把令牌挂上去，但是他又不想排队，又拿上令牌进入自习室，进入自习室肚子又饿也学不好。如此反复，自习室外面的人没有拿到自习室的使用权，而张三又由于肚子饿，也没有利用上这个自习室。
这样就造成了饥饿问题，但是张三有错吗？没错。但是这个策略就有问题
这个时候就要引入条件变量
条件变量
假设自习室门口有一个告示板，上面写着是否允许进入自习室的条件。如果条件不满足（比如自习室满员或者没有空位），学生就在门口等待。当有位置空出时，管理员会在告示板上更新条件，并通知等待的学生。这就是条件变量的基本思想
但是与锁不同的是在这个自习室门口的学生都得排好队，张三出来的时候不能再立马拿令牌，而是要排到队伍后面，这样就解决了饥饿问题。
所以线程排在条件变量的队列里。
