C++ 多线程死锁

最新推荐文章于 2024-05-08 01:24:06 发布

JanzeeLiu

最新推荐文章于 2024-05-08 01:24:06 发布

阅读量366

点赞数

分类专栏： c++ 文章标签： C++d多线程

本文链接：https://blog.csdn.net/qq_36415932/article/details/97575787

版权

c++ 专栏收录该内容

52 篇文章 1 订阅

订阅专栏

面试时经常会问到死锁的以下问题。

产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。

1.互斥条件：在同一时刻，只能允许一个进程访问共享资源；

2.不剥夺条件：进程所使用的资源在未使用完毕之前，不能被其他进程强行夺走，只能由该进程自己释放；

3.请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放；

4.循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被链中下一个进程所请求。

只需要破坏死锁产生的四个条件之一就可以打破死锁：

1.破坏互斥条件：允许某些资源可以共享使用；

2.破坏不剥夺条件：允许进程掌握的资源可以强行被剥夺；

3.破坏请求和保持条件：进程只能在全部申请完所有资源后，才投入运行，这样不会出现在运行时请求资源而不得的情况；

4.破坏循环等待条件：可采用顺序资源分配法，首先给系统的资源编号，进程必须按顺序递增地申请资源，而且相关资源必须一次申请完，也就是说，进程以后申请的资源编号只能大于当前资源编号。

C++提供了4个互斥对象用来对同步多线程对共享资源的访问，防止死锁。

std::mutex  //是最简单的互斥对象
std::mutex  //是带有超时机制的互斥对象，一段时间仍未获得互斥对象所有权的线程会放弃等待
std::recursive_mutex 	//允许被同一个线程递归的Lock和Unlock。
std::recursive_timed_mutex 	
std::shared_timed_mutex	//允许多个线程共享所有权的互斥对象，如读写锁，本文不讨论这种互斥。

锁（lock()函数）

一个线程对互斥对象进行锁操作并成功，就意味着它获得了这个互斥对象的所有权，在此线程对该对象unlock前，其他线程对该对象的lock都会被阻塞，如果该对象已经被该线程调用且没有释放，那么就会产生死锁。

使用RAII管理互斥对象

有以下几个互斥对象管理模板：

std::lock_guard 	//构造时是否加锁是可选的(不加锁时假定当前线程已经获得锁的所有权)，析构时自动释放锁，所有权不可转移，对象生存期内不允许手动加锁和释放锁。
std::unique_lock 	//构造时是否加锁是可选的，在对象析构时如果持有锁会自动释放锁，所有权可以转移。对象生命期内允许手动加锁和释放锁。
std::shared_lock 	//用于管理可转移和共享所有权的互斥对象。

lock_guard的使用如下所示：

#include <thread>
#include <iostream>
#include <string>
class LogFile{
    std::mutex m_mutex;
public:
    void shared_print(std::string id,int value){
        std::lock_guard<std::mutex> locker(m_mutex);
        std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
    }
};

void function_1(LogFile& log){
    for(int i=0;i>-100;--i){
        log.shared_print(std::string("from t1:"),i);
    }
}

int main(){
    LogFile log;
    std::thread t1(function_1,std::ref(log));
    for(int i=0;i<100;++i){
        log.shared_print(std::string("from main:"),i);
    }
    t1.join();
    return 0;
}

部分运行结果如下所示：

from:from main:value:0
from:from main:value:1
from:from main:value:2
from:from main:value:3
from:from main:value:4
from:from main:value:5
from:from main:value:6
from:from main:value:7
from:from main:value:8
from:from main:value:9
from:from main:value:10
from:from main:value:11
from:from main:value:12
from:from main:value:13
from:from main:value:14
from:from main:value:15
from:from main:value:16
from:from main:value:17
from:from main:value:18
from:from main:value:19
from:from main:value:20
from:from main:value:21
from:from main:value:22
from:from main:value:23
from:from main:value:24
from:from main:value:25
from:from main:value:26
from:from main:value:27
from:from main:value:28
from:from main:value:29
from:from main:value:30
from:from main:value:31
from:from main:value:32
from:from main:value:33
from:from main:value:34
from:from main:value:35
from:from main:value:36
from:from main:value:37
from:from main:value:38
from:from main:value:39
from:from main:value:40
from:from main:value:41
from:from main:value:42
from:from main:value:43
from:from main:value:44
from:from main:value:45
from:from main:value:46
from:from main:value:47
from:from main:value:48
from:from main:value:49
from:from main:value:50
from:from main:value:51
from:from main:value:52
from:from main:value:53
from:from main:value:54
from:from main:value:55
from:from t1:value:0
from:from main:value:56
from:from main:value:57
from:from main:value:58
from:from main:value:59
from:from main:value:60
from:from main:value:61
from:from main:value:62
from:from main:value:63
from:from main:value:64
from:from main:value:65
from:from main:value:66
from:from main:value:67
from:from main:value:68
from:from main:value:69
from:from main:value:70
from:from main:value:71
from:from main:value:72
from:from main:value:73
from:from main:value:74
from:from main:value:75
from:from main:value:76
from:from main:value:77
from:from main:value:78
from:from main:value:79
from:from main:value:80
from:from main:value:81
from:from main:value:82
from:from main:value:83
from:from main:value:84
from:from main:value:85
from:from main:value:86
from:from main:value:87
from:from t1:value:-1
from:from t1:value:-2
from:from t1:value:-3
from:from t1:value:-4
from:from t1:value:-5
from:from t1:value:-6
from:from main:value:88
from:from main:value:89
from:from main:value:90
from:from main:value:91
from:from main:value:92

上面的代码对cout添加了锁机制，应该是操作系统使得两个线程轮询使用cout资源，可以看到主线程与子线程的输出是交叉产生的。

下面看一下上面代码产生死锁的情况：

    #include <thread>
    #include <iostream>
    #include <string>
    class LogFile{
        std::mutex m_mutex1;
        std::mutex m_mutex2;
    public:
        void shared_print1(std::string id,int value){
            std::lock_guard<std::mutex> locker1(m_mutex1);
            std::lock_guard<std::mutex> locker2(m_mutex2);
            std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
        }
        void shared_print2(std::string id,int value){
            std::lock_guard<std::mutex> locker2(m_mutex2);
            std::lock_guard<std::mutex> locker1(m_mutex1);
            std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
        }
    };
    
    void function_1(LogFile& log){
        for(int i=0;i>-100;--i){
            log.shared_print1(std::string("from t1:"),i);
        }
    }
    
    int main(){
        LogFile log;
        std::thread t1(function_1,std::ref(log));
        for(int i=0;i<100;++i){
            log.shared_print2(std::string("from main:"),i);
        }
        t1.join();
        return 0;
    }

该程序可能造成死锁，导致程序只能运行出一部分，如下。原因在于，对于主线程，它先锁m_mutex2再锁m_mutex1，如果share_print2运行过程中，锁了m_mutex2之后，子线程已经锁了m_mutex1，此时，主线程等待子线程释放m_mutex2资源，子线程等待主线程释放m_mutex1资源，同时两个线程又紧握自身资源不释放，从而陷入死锁。

from:from main:value:0
from:from main:value:1
from:from main:value:2
from:from main:value:3
from:from main:value:4
from:from main:value:5

改变锁的顺序可以防止此种情况的出现：

    void shared_print2(std::string id,int value){
        std::lock_guard<std::mutex> locker1(m_mutex1);
        std::lock_guard<std::mutex> locker2(m_mutex2);
        std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
    }

也就是说，两个线程必须按照顺序占用资源。

另一种更好的办法是，使用std::lock()函数或者std::try_lock()函数，控制锁住顺序，它的参数不固定，控制N个m_mutex对象。当待加锁的对象中有不可用对象时，std::lock会阻塞当前线程，直到所有对象都可用；std::try_lock不会阻塞线程，当有对象不可用时，会释放已经加锁的其他对象并立即返回。std::adopt_lock告诉locker1，m_mutex1被锁住,locker1需要做的是获取m_mutex1的所有权，在析构时，会解锁m_mutex。

    void shared_print1(std::string id,int value){
        std::lock(m_mutex1,m_mutex2);
        std::lock_guard<std::mutex> locker1(m_mutex1,std::adopt_lock);
        std::lock_guard<std::mutex> locker2(m_mutex2,std::adopt_lock);
        std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
    }
    void shared_print2(std::string id,int value){
        std::lock(m_mutex1,m_mutex2);
        std::lock_guard<std::mutex> locker2(m_mutex2,std::adopt_lock);
        std::lock_guard<std::mutex> locker1(m_mutex1,std::adopt_lock);
        std::cout<<"from:"<<id<<"value:"<<value<<std::endl;
    }

此时程序会输出正确结果，即使顺序不同。

JanzeeLiu

关注

0
点赞
踩
3

收藏

觉得还不错? 一键收藏
0
评论
C++ 多线程死锁

面试时经常会问到死锁的以下问题。产生死锁必须同时满足以下四个条件，只要其中任一条件不成立，死锁就不会发生。1.互斥条件：在同一时刻，只能允许一个进程访问共享资源；2.不剥夺条件：进程所使用的资源在未使用完毕之前，不能被其他进程强行夺走，只能由该进程自己释放；3.请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源已被其他进程占有，此时请求进程被阻塞，但对自...
复制链接

扫一扫