c++多线程编程和死锁问题


C++语言层面 thread
windows -> createThread
linux strace ./a.out -> pthread_create

线程内容

一. 怎么创建启动一个线程

主线程运行完成,查看如果当前进程还有未运行完成的子线程
进程就会异常终止

void threadHandle1(int time)
{
	// 让子线程睡眠time秒
	std::this_thread::sleep_for(std::chrono::seconds(time));
	cout << "hello thread1!" << endl;
}
void threadHandle2(int time)
{
	// 让子线程睡眠time秒
	std::this_thread::sleep_for(std::chrono::seconds(time));
	cout << "hello thread2!" << endl;
}

// 创建了一个线程对象,传入一个线程函数,新线程就开始运行了
	std::thread t1(threadHandle1, 2);
	std::thread t2(threadHandle2, 3);
// 主线程等待子线程结束,主线程继续往下运行
	t1.join();
	t2.join();
// 把子线程设置为分离线程
	//t1.detach();

二. 子线程如何结束

子线程函数运行完成,线程就结束了

三. 主线程如何处理子线程

t.join() : 等待t线程结束,当前线程继续往下运行
t.detach() : 把t线程设置为分离线程,主线程结束,整个进程结束,所有子线程都自动结束了!

线程间的互斥

// 临界区代码段 =》 原子操作 =》 线程间互斥操作了 =》 mutex

在多线程环境中运行的代码段,需要考虑是否存在竞态条件,如果存在竞态条件,我们就说该代码段不是线程安全的,不能直接运行在多线程环境当中,对于这样的代码段,我们经常称之为临界区资源,对于临界区资源,多线程环境下需要保证它以原子操作执行,要保证临界区的原子操作,就需要用到线程间的互斥操作-锁机制,thread类库还提供了更轻量级的基于CAS操作的原子操作类。

下面用模拟3个窗口同时卖票的场景,用代码示例一下线程间的互斥操作。

thread线程类库的互斥锁mutex

这样会卖票重复,线程不安全
竞态条件:多线程程序执行的结果是一致的,不会随着CPU对线程不同的调用顺序,而产生不同的运行结果

void sellTicket(int index)
{
	while (ticketCount > 0) 
	{
		cout << "窗口:" << index << "卖出第:" << ticketCount << "张票!" << endl;
			//cout << ticketCount << endl;
		ticketCount--; //线程不安全
		std::this_thread::sleep_for(std::chrono::milliseconds(100));
	}
}

int main()
{
	list<std::thread> tlist;
	for (int i = 1; i <= 3; ++i)
	{
		tlist.push_back(std::thread(sellTicket, i));
	}

	for (std::thread &t : tlist)
	{
		t.join();
	}

	cout << "所有窗口卖票结束!" << endl;

	return 0;
}

在这里插入图片描述

解决–锁

加双重判断
可能出现线程1获取锁,线程2在等
线程1把最后一张票卖完了解锁;
线程2进来了,然后卖出负票

// 模拟卖票的线程函数  lock_guard unique_lock
void sellTicket(int index)
{
	while (ticketCount > 0) // ticketCount=1  锁+双重判断
	{
		//mtx.lock();
		{
			// 保证所有线程都能释放锁,防止死锁问题的发生 scoped_ptr
			lock_guard<std::mutex> lock(mtx); 
			if (ticketCount > 0)
			{
				// 临界区代码段  =》  原子操作 =》 线程间互斥操作了 =》 mutex
				cout << "窗口:" << index << "卖出第:" << ticketCount << "张票!" << endl;
				//cout << ticketCount << endl;
				ticketCount--;
			}
		}
		//mtx.unlock();
		std::this_thread::sleep_for(std::chrono::milliseconds(100));
	}
}

问题mtx.unlock 如果临界区里面return返回了,就访问不到了,所以用职智能锁

  • lock_guard<std::mutex> lock(mtx);
  • lock_guard 吧拷贝构造和复制重载全删了,类似scoped_ptr
  • unique_lock 类似 unique_ptr
unique_lock<std::mutex> lck(mtx);
lck.lock();
lck.unlock();

thread线程类库基于CAS的原子类

实际上,上面代码中因为tickets车票数量是整数,因此它的- -操作需要在多线程环境下添加互斥操作,但是mutex互斥锁毕竟比较重,对于系统消耗有些大,C++11的thread类库提供了针对简单类型的原子操作类,如std::atomic_int,atomic_long,atomic_bool等,它们值的增减都是基于CAS操作的,既保证了线程安全,效率还非常高。

下面代码示例开启10个线程,每个线程对整数增加1000次,保证线程安全的情况下,应该加到10000次,这种情况下,可以用atomic_int来实现,代码示例如下:

#include <iostream>
#include <atomic> // C++11线程库提供的原子类
#include <thread> // C++线程类库的头文件
#include <vector>

// 原子整形,CAS操作保证给count自增自减的原子操作
std::atomic_int count = 0;

// 线程函数
void sumTask()
{
	// 每个线程给count加1000次
	for (int i = 0; i < 1000; ++i)
	{
		count++;
	}
}

int main()
{
	// 创建10个线程放在容器当中
	std::vector<std::thread> vec;
	for (int i = 0; i < 10; ++i)
	{
		vec.push_back(std::thread(sumTask));
	}

	// 等待线程执行完成
	for (int i = 0; i < vec.size(); ++i)
	{
		vec[i].join();
	}

	// 所有子线程运行结束,count的结果每次运行应该都是10000
	std::cout << "count : " << count << std::endl;

	return 0;
}

实际上,C++11类库的原子操作类,在Linux平台下调用的也是CAS(compare_and_set)相关的系统接口。

线程间的同步通信机制

多线程在运行过程中,各个线程都是随着OS的调度算法,占用CPU时间片来执行指令做事情,每个线程的运行完全没有顺序可言。但是在某些应用场景下,一个线程需要等待另外一个线程的运行结果,才能继续往下执行,这就需要涉及线程之间的同步通信机制。

线程间同步通信最典型的例子就是生产者-消费者模型,生产者线程生产出产品以后,会通知消费者线程去消费产品;如果消费者线程去消费产品,发现还没有产品生产出来,它需要通知生产者线程赶快生产产品,等生产者线程生产出产品以后,消费者线程才能继续往下执行。

简单介绍

  • lock_guard
    不可能用在函数参数或者返回过程中,只能用在简单的代码临界区代码段的互斥操作中
    lock_guard guard(mtx);
  • unique_lock
    unique_lock<std::mute> lck(mtx);
    不仅可以使用再简单的临界区代码段的互斥操作中,还能用在函数调用过程中
  • cv.wait(lck);
    #1.使线程进入等待状态 #2.lck.unlock可以把mtx给释放掉
  • cv.notify_all();
    通知在cv上等待的线程,条件成立了,起来干活了!
    其它在cv上等待的线程,收到通知,从等待状态 =》 阻塞状态 =》 获取互斥锁了 =》线程继续往下执行

生产者消费者模型

C++11 线程库提供的条件变量condition_variable,就是Linux平台下的Condition Variable机制,用于解决线程间的同步通信问题,下面通过代码演示一个生产者-消费者线程模型,仔细分析代码:

#include "iostream"
#include "queue" // C++STL所有的容器都不是线程安全的
#include "condition_variable"
#include "memory"
#include "thread"
using namespace std;
mutex mtx; // 定义互斥锁,做线程间的互斥操作
condition_variable cv; //定义条件变量,做线程间的同步通信
// 生产者生成一个物品,通知消费者消费一个;消费完了,消费者再通知生产者继续生成物品
class Queue{
public:
    void put(int val){ //生产物品
//        lock_guard<mutex> guard(mtx);
        unique_lock<mutex> lck(mtx);
        if(!q.empty()){
            // q不为空,生产者通知消费者去消费,消费完了,再继续生产
            //生产者应该进入#1等待状态,并且#2把mtx互斥锁释放掉
            cv.wait(lck);
        }
        q.push(val);
        /*
         * notify_one:通知另外的一个线程
         * notify_all:通知其他所有线程
         * 通知其他所有的线程,我生产一个物品,你们赶紧消费吧
         * 其他的现成得到通知,就会从等待状态=》阻塞状态=》获取互斥锁才能继续执行
         * */
        cv.notify_all();
        cout << "生产者 生产:" << val << "号物品" << endl;
    }
    int get(){ //消费物品
//        lock_guard<mutex> guard(mtx);
        unique_lock<mutex> lck(mtx);
        while(q.empty()){
            // 消费者线程发现que是空的,通知生产者线程先生成物品
            // #1 进入等待状态  #2 把互斥锁mutex释放

            cv.wait(lck);
        }
        int val = q.front();
        q.pop();
        //通知其他线程,我消费完了,赶紧生产吧
        cv.notify_all();
        cout << "消费者 消费:" << val << "号物品" << endl;
        return val;
    }

private:
    queue<int> q;
};
void product(Queue *q){
    for(int i = 0; i <= 10; ++i){
        q->put(i);
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}

void consumer(Queue *q){
    for(int i = 0; i <= 10; ++i){
        q->get();
        std::this_thread::sleep_for(std::chrono::milliseconds(100));
    }
}


int main(){
    Queue q; //俩个线程共享的队列
    thread t1(product, &q);
    thread t2(consumer, &q);
    t1.join();
    t2.join();
}

在这里插入图片描述

基于CAS操作的atomic原子类型

窗口卖票 int count=100;
lock_guardstd::mutex guard(mtx);
count++;

lock_guardstd::mutex guard(mtx);
count–;

互斥锁是比较重的,临界区代码做的事情稍稍复杂,多
系统理论:CAS来保证上面++ --操作的原子特性就足够了, 无锁操作
exchange/swap 无锁队列 => CAS来实现的

volatile std::atomic_bool isReady = false;
volatile std::atomic_int mycount = 0;

void task()
{
	while (!isReady)
	{
		std::this_thread::yield(); // 线程出让当前的CPU时间片,等待下一次调度
	}

	for (int i = 0; i < 100; ++i)
	{
		mycount++;
	}
}
int main()
{
	list<std::thread> tlist;
	for (int i = 0; i < 10; ++i)
	{
		tlist.push_back(std::thread(task));
	}

	std::this_thread::sleep_for(std::chrono::seconds(3));
	isReady = true;

	for (std::thread &t : tlist)
	{
		t.join();
	}
	cout << "mycount:" << mycount << endl;

	return 0;
}

死锁问题案例分析解决

死锁的问题经常会考察到,面对哪些情况下会程序会发生死锁的问题,与其想着怎么把书上的理论背出来,不如从实践的角度举例说明,如何对死锁的问题进行分析定位,然后找到问题点进行修改。

当我们的程序运行时,出现假死的现象,有可能是程序死循环了,有可能是程序等待的I/O、网络事件没发生导致程序阻塞了,也有可能是程序死锁了,下面举例说明在Linux系统下如何分许我们程序的死锁问题。

示例:
当一个程序的多个线程获取多个互斥锁资源的时候,就有可能发生死锁问题,比如线程A先获取了锁1,线程B获取了锁2,进而线程A还需要获取锁2才能继续执行,但是由于锁2被线程B持有还没有释放,线程A为了等待锁2资源就阻塞了;线程B这时候需要获取锁1才能往下执行,但是由于锁1被线程A持有,导致A也进入阻塞。

线程A和线程B都在等待对方释放锁资源,但是它们又不肯释放原来的锁资源,导致线程A和B一直互相等待,进程死锁了。下面代码示例演示这个问题:

#include <iostream>           // std::cout
#include <thread>             // std::thread
#include <mutex>              // std::mutex, std::unique_lock
#include <condition_variable> // std::condition_variable
#include <vector>

// 锁资源1
std::mutex mtx1;
// 锁资源2
std::mutex mtx2;

// 线程A的函数
void taskA()
{
	// 保证线程A先获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程A获取锁1" << std::endl;

	// 线程A睡眠2s再获取锁2,保证锁2先被线程B获取,模拟死锁问题的发生
	std::this_thread::sleep_for(std::chrono::seconds(2));

	// 线程A先获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程A获取锁2" << std::endl;

	std::cout << "线程A释放所有锁资源,结束运行!" << std::endl;
}

// 线程B的函数
void taskB()
{
	// 线程B先睡眠1s保证线程A先获取锁1
	std::this_thread::sleep_for(std::chrono::seconds(1));
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程B获取锁2" << std::endl;

	// 线程B尝试获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程B获取锁1" << std::endl;

	std::cout << "线程B释放所有锁资源,结束运行!" << std::endl;
}
int main()
{
	// 创建生产者和消费者线程
	std::thread t1(taskA);
	std::thread t2(taskB);

	// main主线程等待所有子线程执行完
	t1.join();
	t2.join();

	return 0;
}

运行上面的程序,打印如下:

tony@tony-virtual-machine:~/code$ ./a.out 
线程A获取锁1
线程B获取锁2

可以看到,线程A获取锁1、线程B获取锁2以后,进程就不往下继续执行了,一直等待在这里,如果这是我们碰到的一个问题场景,我们如何判断出这是由于线程间死锁引起的呢?

先通过ps命令查看一下进程当前的运行状态和PID,如下:
root@tony-virtual-machine:/home/tony# ps -aux | grep a.out
tony 1953 0.0 0.0 98108 1904 pts/0 Sl+ 10:41 0:00 ./a.out
root 2064 0.0 0.0 21536 1076 pts/1 S+ 10:51 0:00 grep --color=auto a.out
从上面的命令可以看出,a.out进程的PID是1953,当前状态是Sl+,相当于是多线程程序,全部进入阻塞状态。

通过top命令再查看一下进程内每个线程具体的运行情况,如下:
root@tony-virtual-machine:/home/tony# top -Hp 1953

进程 USER PR NI VIRT RES SHR CPU %MEM TIME+ COMMAND
1953 tony 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out
1954 tony 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out
1955 tony 20 0 98108 1904 1752 S 0.0 0.1 0:00.00 a.out

从top命令的打印信息可以看出,所有线程都进入阻塞状态,CPU占用率都为0.0,可以排除是死循环的问题,因为死循环会造成CPU使用率居高不下,而且线程的状态也不会是S。那么接下来有可能是由于I/O网络事件没有发生使线程阻塞,或者是线程发生死锁问题了。

通过gdb远程调试正在运行的程序,打印进程每一个线程的调用堆栈信息,过程如下:
通过gdb attach pid远程调试上面的a.out进程,命令如下:
root@tony-virtual-machine:/home/tony# gdb attach 1953

进入gdb调试命令行以后,打印所有线程的调用栈信息,信息如下:
(gdb) thread apply all bt

Thread 3 (Thread 0x7feb523ec700 (LWP 1955)):
#0 _llllock_wait () at …/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7140 ) at …/nptl/pthread_mutex_lock.c:78
#2 0x00005646aa9e40bf in __gthread_mutex_lock(pthread_mutex_t*) ()
#3 0x00005646aa9e4630 in std::mutex::lock() ()
#4 0x00005646aa9e46ac in std::lock_guardstd::mutex::lock_guard(std::mutex&) ()
#5 0x00005646aa9e42c0 in taskB() ()
#6 0x00005646aa9e4bdb in void std::__invoke_impl<void, void ()()>(std::__invoke_other, void (&&)()) ()
#7 0x00005646aa9e49e8 in std::__invoke_result<void ()()>::type std::__invoke<void ()()>(void (&&)()) ()
#8 0x00005646aa9e50b6 in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<void ()()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#9 0x00005646aa9e5072 in std::thread::_Invoker<std::tuple<void ()()> >::operator()() ()
#10 0x00005646aa9e5042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void ()()> > >::_M_run() ()
#11 0x00007feb5365257f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007feb539256db in start_thread (arg=0x7feb523ec700) at pthread_create.c:463
#13 0x00007feb530ad88f in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7feb52bed700 (LWP 1954)):
#0 _llllock_wait () at …/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7180 ) at …/nptl/pthread_mutex_lock.c:78
#2 0x00005646aa9e40bf in __gthread_mutex_lock(pthread_mutex_t*) ()
#3 0x00005646aa9e4630 in std::mutex::lock() ()
#4 0x00005646aa9e46ac in std::lock_guardstd::mutex::lock_guard(std::mutex&) ()
#5 0x00005646aa9e4183 in taskA() ()
#6 0x00005646aa9e4bdb in void std::__invoke_impl<void, void ()()>(std::__invoke_other, void (&&)()) ()
#7 0x00005646aa9e49e8 in std::__invoke_result<void ()()>::type std::__invoke<void ()()>(void (&&)()) ()
#8 0x00005646aa9e50b6 in decltype (__invoke((_S_declval<0ul>)())) std::thread::_Invoker<std::tuple<void ()()> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) ()
#9 0x00005646aa9e5072 in std::thread::_Invoker<std::tuple<void ()()> >::operator()() ()
#10 0x00005646aa9e5042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void ()()> > >::_M_run() ()
#11 0x00007feb5365257f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007feb539256db in start_thread (arg=0x7feb52bed700) at pthread_create.c:463
#13 0x00007feb530ad88f in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7feb53d4b740 (LWP 1953)):
—Type to continue, or q to quit—
#0 0x00007feb53926d2d in __GI___pthread_timedjoin_ex (threadid=140648682280704, thread_return=0x0, abstime=0x0,
block=) at pthread_join_common.c:89
#1 0x00007feb536527d3 in std::thread::join() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#2 0x00005646aa9e43bb in main ()
(gdb)

从上面的线程调用栈信息可以看到,当前进程有三个线程,分别是Thread1是main线程,Thread2是taskA线程,Thread3是taskB线程。

从调用栈信息可以看到,Thread3线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at,也就是它在等待获取一把锁(lock_wait),而且堆栈信息打印的很清晰,#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7140 ) at …/nptl/pthread_mutex_lock.c:78,Thread3在获取而获取不到,因此进入阻塞状态了。这里结合代码分析,Thread3线程(也就是taskB)最后在这里阻塞了:
void taskB()
{
// 线程B先睡眠1s保证线程A先获取锁1
std::this_thread::sleep_for(std::chrono::seconds(1));
std::lock_guardstd::mutex lockB(mtx2);
std::cout << “线程B获取锁2” << std::endl;
// 线程B尝试获取锁1
std::lock_guardstd::mutex lockA(mtx1); ===》 这里阻塞了!如果不知道怎么定位到源代码行上,看下一小节!
std::cout << “线程B获取锁1” << std::endl;
std::cout << “线程B释放所有锁资源,结束运行!” << std::endl;
}

依然是从调用栈信息可以看到,Thread2线程进入S阻塞状态的原因是因为它最后在#0 _llllock_wait () at,也就是它在等待获取一把锁(lock_wait),而且堆栈信息打印的很清晰,#1 0x00007feb53928023 in __GI___pthread_mutex_lock (mutex=0x5646aabe7180 ) at …/nptl/pthread_mutex_lock.c:78,Thread2在获取而获取不到,因此进入阻塞状态了。这里结合代码分析,Thread2线程(也就是taskA)最后在这里阻塞了:
void taskA()
{
// 保证线程A先获取锁1
std::lock_guardstd::mutex lockA(mtx1);
std::cout << “线程A获取锁1” << std::endl;
// 线程A睡眠2s再获取锁2,保证锁2先被线程B获取,模拟死锁问题的发生
std::this_thread::sleep_for(std::chrono::seconds(2));
// 线程A先获取锁2
std::lock_guardstd::mutex lockB(mtx2); ===》 这里阻塞了!如果不知道怎么定位到源代码行上,看下一小节!
std::cout << “线程A获取锁2” << std::endl;
std::cout << “线程A释放所有锁资源,结束运行!” << std::endl;
}

既然定位到taskA和taskB线程阻塞的原因,都是因为锁获取不到,然后再结合源码进行分析定位,最终发现taskA之所以获取不到mtx2,是因为mtx2早被taskB线程获取了;同样taskB之所以获取不到mtx1,是因为mtx1早被taskA线程获取了,导致所有线程进入阻塞状态,等待锁资源的获取,但是又因为没有线程释放锁,最终导致死锁问题。(从各线程调用栈信息能看出来,这里面和I/O网络事件没什么关系)

怎么在源码上定位到问题代码

实际上,上面的代码运行一般是发布后的release版本,内部没有调试信息,我们如果想把死锁的原因定位到源码的某一行代码上,就需要一个debug版本(g++编译添加-g选项),操作如下:
1.编译命令
tony@tony-virtual-machine:~/code$ g++ 20190316.cpp -g -lpthread
2. 运行代码
tony@tony-virtual-machine:~/code$ ./a.out
线程A获取锁1
线程B获取锁2
…(程序到这里不往下运行了)
3.gdb调试该进程
root@tony-virtual-machine:/home/tony/code# ps -ef | grep a.out
tony 2617 1535 0 12:32 pts/0 00:00:00 ./a.out
root@tony-virtual-machine:/home/tony/code# gdb attach 2617
4.查看当前所有的线程
(gdb) info threads

  Id   Target Id         Frame 
* 1    Thread 0x7f8c63002740 (LWP 2617) "a.out" 0x00007f8c62bddd2d in __GI___pthread_timedjoin_ex (
    threadid=140240914892544, thread_return=0x0, abstime=0x0, block=<optimized out>) at pthread_join_common.c:89
  2    Thread 0x7f8c61ea4700 (LWP 2618) "a.out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
  3    Thread 0x7f8c616a3700 (LWP 2619) "a.out" __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135

可以看到有三个线程。

5.切换到线程2
(gdb) thread 2
6.查看线程2目前的调用栈信息,where或者bt命令都可以
(gdb) where

(gdb) where
#0  __lll_lock_wait () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:135
#1  0x00007f8c62bdf023 in __GI___pthread_mutex_lock (mutex=0x55678928e180 <mtx2>) at ../nptl/pthread_mutex_lock.c:78
#2  0x000055678908b0bf in __gthread_mutex_lock (__mutex=0x55678928e180 <mtx2>)
    at /usr/include/x86_64-linux-gnu/c++/7/bits/gthr-default.h:748
#3  0x000055678908b630 in std::mutex::lock (this=0x55678928e180 <mtx2>) at /usr/include/c++/7/bits/std_mutex.h:103
#4  0x000055678908b6ac in std::lock_guard<std::mutex>::lock_guard (this=0x7f8c61ea3dc0, __m=...)
    at /usr/include/c++/7/bits/std_mutex.h:162
#5  0x000055678908b183 in taskA () at 20190316.cpp:23
#6  0x000055678908bbdb in std::__invoke_impl<void, void (*)()> (__f=@0x556789d78e78: 0x55678908b0f7 <taskA()>)
    at /usr/include/c++/7/bits/invoke.h:60
#7  0x000055678908b9e8 in std::__invoke<void (*)()> (__fn=@0x556789d78e78: 0x55678908b0f7 <taskA()>)
    at /usr/include/c++/7/bits/invoke.h:95
#8  0x000055678908c0b6 in std::thread::_Invoker<std::tuple<void (*)()> >::_M_invoke<0ul> (this=0x556789d78e78)
    at /usr/include/c++/7/thread:234
#9  0x000055678908c072 in std::thread::_Invoker<std::tuple<void (*)()> >::operator() (this=0x556789d78e78)
    at /usr/include/c++/7/thread:243
#10 0x000055678908c042 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<void (*)()> > >::_M_run (
    this=0x556789d78e70) at /usr/include/c++/7/thread:186
#11 0x00007f8c6290957f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007f8c62bdc6db in start_thread (arg=0x7f8c61ea4700) at pthread_create.c:463
#13 0x00007f8c6236488f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

7.查看上面线程2的第5帧信息#5 0x000055678908b183 in taskA () at 20190316.cpp:23
(gdb) f 5
#5 0x000055678908b183 in taskA () at 20190316.cpp:23
23 std::lock_guard< std::mutex > lockB(mtx2);
可以看到,这里就直接定位到代码一直阻塞在了20190316.cpp的第23行,对应的行代码是std::lock_guard< std::mutex > lockB(mtx2);

可以同样的步骤定位查看线程3的问题代码行。

死锁问题代码修改

既然发现了问题,那么就知道这个问题场景发生死锁,是由于多个线程获取多个锁资源的时候,顺序不一致导致的死锁问题,那么保证它们获取锁的顺序是一致的,问题就可以解决,代码修改如下:

#include <iostream>           // std::cout
#include <thread>             // std::thread
#include <mutex>              // std::mutex, std::unique_lock
#include <condition_variable> // std::condition_variable
#include <vector>

// 锁资源1
std::mutex mtx1;
// 锁资源2
std::mutex mtx2;

// 线程A的函数
void taskA()
{
	// 保证线程A先获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程A获取锁1" << std::endl;

	// 线程A尝试获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程A获取锁2" << std::endl;

	std::cout << "线程A释放所有锁资源,结束运行!" << std::endl;
}

// 线程B的函数
void taskB()
{
	// 线程B获取锁1
	std::lock_guard<std::mutex> lockA(mtx1);
	std::cout << "线程B获取锁1" << std::endl;

	// 线程B尝试获取锁2
	std::lock_guard<std::mutex> lockB(mtx2);
	std::cout << "线程B获取锁2" << std::endl;

	std::cout << "线程B释放所有锁资源,结束运行!" << std::endl;
}
int main()
{
	// 创建生产者和消费者线程
	std::thread t1(taskA);
	std::thread t2(taskB);

	// main主线程等待所有子线程执行完
	t1.join();
	t2.join();

	return 0;
}

程序运行正常,打印如下:

线程A获取锁1
线程A获取锁2
线程A释放所有锁资源,结束运行!
线程B获取锁1
线程B获取锁2
线程B释放所有锁资源,结束运行!
  • 4
    点赞
  • 14
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
《Linux多线程服务端编程:使用muduo C++网络库》主要讲述采用现代C++在x86-64 Linux上编写多线程TCP网络服务程序的主流常规技术,重点讲解一种适应性较强的多线程服务器的编程模型,即one loop per thread。 目 录 第1部分C++线程系统编程 第1章线程安全的对象生命期管理3 1.1当析构函数遇到多线程. . . . . . . . . . . . . . . . .. . . . . . . . . . . 3 1.1.1线程安全的定义. . . . . . . . . . . . . . . . .. . . . . . . . . . . 4 1.1.2MutexLock 与MutexLockGuard. . . . . . . . . . . . . . . . . . . . 4 1.1.3一个线程安全的Counter 示例.. . . . . . . . . . . . . . . . . . . 4 1.2对象的创建很简单. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 5 1.3销毁太难. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 7 1.3.1mutex 不是办法. . . . . . . . . . . . . . . . . . . .. . . . . . . . 7 1.3.2作为数据成员的mutex 不能保护析构.. . . . . . . . . . . . . . 8 1.4线程安全的Observer 有多难.. . . . . . . . . . . . . . . . . . . . . . . . 8 1.5原始指针有何不妥. . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 11 1.6神器shared_ptr/weak_ptr . . . . . . . . . .. . . . . . . . . . . . . . . . 13 1.7插曲:系统地避免各种指针错误. . . . . . . . . . . . . . . . .. . . . . . 14 1.8应用到Observer 上.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 1.9再论shared_ptr 的线程安全.. . . . . . . . . . . . . . . . . . . . . . . . 17 1.10shared_ptr 技术与陷阱. . . .. . . . . . . . . . . . . . . . . . . . . . . . 19 1.11对象池. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . 21 1.11.1enable_shared_from_this . . . . . . . . . . . . . . . . . . . . . . 23 1.11.2弱回调. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . 24 1.12替代方案. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . 26 1.13心得与小结. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . 26 1.14Observer 之谬. . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 第2章线程同步精要 2.1互斥器(mutex). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.1.1只使用非递归的mutex . . . . . . . . . . . . . .. . . . . . . . . . 33 2.1.2. . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 35 2.2条件变量(condition variable). . . . . . . . . .

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值