线程保护共享数据,操作时,某个线程用代码把共享数据锁住,其他想操作共享数据的线程必须等待;等待解锁,其他线程才能继续操作共享数据。
1)锁定住
2)操作
3)解锁
“互斥量”的基本概念,互斥量是个类对象,理解成一把锁,多个线程尝试用lock()成员函数来加锁这个锁头,只有一个线程能锁定成功,只要返回了表示锁成功了,如果没锁成功,那么流程就会卡在Lock()这里不断尝试去锁,如果永远不成功就“死锁”。
首先,使用互斥量需要引入一个头
#include <mutex>
线程先lock(),操作共享数据,然后操作完之后,unlock();
lock()和unlock()要成对使用,有lock()必然要有unlock,每调用一次lock(),必然应该调用一次unlock()。不应该出现一次lock(),两次unlock(),非对称的数据调用必然会出错!!!lock和unlock用来保护代码,由程序开发者决定,明确决定从哪里保护到哪。
class ProcessRequest { public: //把命令加入到一个队列 void inMsgRecvQueue() { for (int i = 0; i < 100000; ++i) { my_mutex.lock(); cout << "插入一个元素" << endl; m_msgRecvQueue.push_back(i); //假设这个队列表示玩家的命令 my_mutex.unlock(); } //占用时间片 } bool outMsgLULProc(int &command) { if (!m_msgRecvQueue.empty()) { int command = m_msgRecvQueue.front(); m_msgRecvQueue.pop_front(); return true; } return false; } //把命令移出一个队列 void outMsgRecvQueue() { int command = 0; for (int i = 0; i < 100000; ++i) { my_mutex.lock(); bool result = outMsgLULProc(command); if (result == true) { cout << "outMsgRecvQueue() 执行,取出一个元素" << endl; } else { cout << "outMsgRecvQueue() 还执行,但是消息队列为空" << endl; //消息队列为空 } my_mutex.unlock(); //占用时间片 } } private: std::list<int> m_msgRecvQueue; //容器,用于表示玩家的发送过来命令 std::mutex my_mutex; };
为了防止忘记写unlock,std::lock_guard,可以自动unlock,功能类似unique_ptr。类模板可以直接取代lock和unlock,同时取代两个,也就是说用了lock_guard之后不能使用lock和unlock了。
lock_guard构造函数里执行了 mutex::lock(),在析构函数里执行了mutex::unlock()。超出作用域析构,不用担心结果。
在操作系统中,进程互相竞争资源,但是资源有限,都在等待占用资源,运行完毕释放资源。C++中,至少两个锁才会产生死锁问题,一把锁不会产生死锁。多线程以及多进程改善了系统资源的利用率并提高了系统 的处理能力。然而,并发执行也带来了新的问题——死锁。
死锁是指两个或两个以上的进程(线程)在运行过程中因争夺资源而造成的一种僵局(Deadly-Embrace) ) ,若无外力作用,这些进程(线程)都将无法向前推进。
某计算机系统中只有一台打印机和一台输入设备,进程P1正占用输入设备,同时又提出使用打印机的请求,但此时打印机正被进程P2 所占用,而P2在未释放打印机之前,又提出请求使用正被P1占用着的输入设备。这样两个进程相互无休止地等待下去,均无法继续执行,此时两个进程陷入死锁状态。
关于死锁的一些结论:
a)参与死锁的进程数至少为两个
b)参与死锁的所有进程均等待资源
c)参与死锁的进程至少有两个已经占有资源
d)死锁进程是系统中当前进程集合的一个子集
e)死锁会浪费大量系统资源,甚至导致系统崩溃
两个线程A和B:
a)A执行的时候,先锁金锁,金锁lock()成功,程序往下走,然后lock()银锁,还没锁成功,此时因为线程调度,上下文切换,一不小心,线程A切换走了。
b)线程B得到了执行的权限,先锁银锁,然后线程B要去lock金锁,此时此刻,死锁产生了。
分析:线程A,拿着金锁,等银锁。线程B,拿着银锁,等金锁。此时,两个线程流程都走不下去,所以后面的代码有解锁金锁的解不开,线程B拿不到金锁,流程走不下去,银锁解不开。
只要调用顺序保持一致,就不会死锁。
Processor1{ mutex1.lock(); mutex2.lock(); // .... // mutex1.unlock(); mutex2.unlock(); } Processor2{ mutex1.lock(); mutex2.lock(); // ... // mutex1.unlock(); mutex2.unlock(); }
std::adopt_lock是个结构体对象,起一个标记的作用:这个互斥量已经lock(),不需要std::lock_guard<std:mutex> 构造函数里面再面对Mutex对象进行lock()。
参考文献
https://blog.csdn.net/wljliujuan/article/details/79614019
原文:https://www.cnblogs.com/rynerlute/p/11809616.html