目录
2. std::recursive_mutex(递归互斥锁)
4. std::recursive_timed_mutex (递归时间互斥锁)
一、thread类的基本介绍
在C++11之前,涉及到多线程问题,都是和平台相关的,比如windows和linux下各有自己的接口,这使得代码的可移植性比较差。C++11中最重要的特性就是对线程进行支持了,使得C++在并行编程时不需要依赖第三方库,而且在原子操作中还引入了原子类的概念。要使用标准库中的线程,必须包含< thread >头文 件。
二、线程库 —— thread
1. 线程对象的构造方法
构造出一个线程对象,可以采用无参构造、带参构造和移动构造;
1. 无参构造
//1.无参构造
thread t1;
使用无参构造出来的线程对象没有关联任何线程函数,即没有启动任何线程。
2. 带参构造
//定义如下:
template <class Fn, class... Args>
explicit thread (Fn&& fn, Args&&... args);
参数:
- fn:它是一个万能引用,可以接收:函数指针、仿函数、lambda表达式、被包装器包装后的可调用对象等。
- args:调用可调用对象fn时所需要的若干参数。
void func(int x)
{
cout << x << endl;
}
int main()
{
//2.带参构造
thread t2(func, 10);
thread t3([]() {cout << "hello" << endl; });
t2.join();
t3.join();
return 0;
}
3. 移动构造
void func(int x)
{
cout << x << endl;
}
int main()
{
//3.移动构造
thread t4 = thread(func, 10);
t4.join();
return 0;
}
注意:
- 线程是操作系统中的一个概念,线程对象可以关联一个线程,用来控制线程以及获取线程的状态。
- 如果创建线程对象时没有提供线程函数,那么该线程对象实际没有对应任何线程。
- 如果创建线程对象时提供了线程函数,那么就会启动一个线程来执行这个线程函数,该线程与主线程一起运行。
- thread类是防拷贝的,不允许拷贝构造和拷贝赋值,但是可以移动构造和移动赋值,可以将一个线程对象关联线程的状态转移给其他线程对象,并且转移期间不影响线程的执行。
2. thread提供的成员函数
成员函数 | 功能 |
---|---|
get_id | 获取线程id |
joinable | 判断该线程是否执行完毕,如果是则返回true,反之false |
join | 该函数调用后会阻塞住该线程,当该线程结束后,主线程继续执行 |
detach | 将线程对象与被创建的线程进行分离,被分离后的线程不在需要调用join函数进行等待,即创建出来的线程的“死活”与主线程无关 |
swap | 将两个线程对象关联的状态进行交换 |
- 采用无参构造函数构造的线程对象
- 线程对象的状态已经转移给其他线程对象
- 线程已经调用jion或者detach结束
3. 获取线程id
调用thread的成员函数get_id可以获取线程的id,但该方法必须通过线程对象来调用get_id函数,如果要在线程对象关联的线程函数中获取线程id,可以调用this_thread命名空间下的get_id函数。比如:
void func()
{
cout << this_thread::get_id() << endl; //获取线程id
}
int main()
{
thread t(func);
t.join();
return 0;
}
this_thread 命名空间中还提供了以下三个函数:
函数名 | 功能 |
---|---|
yield | 当前线程“放弃”执行,让操作系统调用另一个线程继续执行 |
sleep_until | 让当前线程休眠到一个具体的时间点 |
sleep_for | 让当前线程休眠一个时间段 |
4. 线程函数的参数问题
线程函数的参数是以值拷贝的方式拷贝到线程栈空间中的,因此:即使线程参数为引用类型,在线程中修改后也不能修改外部实参,因为其实际引用的是线程栈中的拷贝,而不是外部实参。如:
我们想通过线程对一个变量进行修改,应该写法如下:
void func(int& x)
{
x++;
}
int main()
{
int n = 0;
thread t1(func, n);
t1.join();
cout << n << endl;
return 0;
}
但是编译器直接报错了;
解决方案1:采用C语言的方式,使用指针
void func(int* x)
{
(*x)++;
}
int main()
{
int n = 0;
thread t1(func, &n);
t1.join();
cout << n << endl;
return 0;
}
解决方案2: 借助std::ref函数
当线程函数的参数类型为引用类型时,如果要想线程函数形参引用的是外部传入的实参,而不是线程栈空间中的拷贝,那么在传入实参时需要借助ref函数保持对实参的引用。
void func(int& x)
{
x++;
}
int main()
{
int n = 0;
thread t1(func, std::ref(n));
t1.join();
cout << n << endl;
return 0;
}
解决方案3:借助lambda表达式
int main()
{
int n = 0;
thread t1([&n]() {n++; });
t1.join();
cout << n << endl;
return 0;
}
5. join和detach
启动了一个线程后,当这个线程结束的时候,如何去回收线程所使用的资源呢?thread库给我们两种选择:
1. join( )方式
join():主线程被阻塞,当新线程终止时,join()会清理相关的线程资源,然后返回,主线程再继续向下执行,然后销毁线程对象。由于join()清理了线程的相关资源,thread对象与已销毁的线程就没有关系了, 因此一个线程对象只能使用一次join() ,否则程序会崩溃。
void func(int n)
{
//.....
}
int main()
{
thread t1(func, 10);
t1.join();
t1.join(); //程序崩溃
return 0;
}
但采用join的方式结束线程,在某些场景下也可能会出现问题。比如在该线程被join之前,如果中途因为某些原因导致程序不再执行后续代码,这时这个线程将不会被join。
void func(int n)
{
for (int i = 0; i <= n; i++)
{
cout << i << endl;
}
}
bool DoSomething()
{
return false;
}
int main()
{
thread t(func, 20);
if (!DoSomething())
return -1;
t.join(); //不会被执行
return 0;
}
//说明:如果DoSomething()函数返回false,主线程将会结束,
//jion()没有调用,线程资源没有回收,造成资源泄漏
RAII,即Resource Acquisition Is Initialization,在初始化中获取资源。RAII机制,通过在栈上创建临时变量,这样临时变量就接管了堆上内存的控制权,当该临时变量声明周期结束时,则对应的堆上内存自然就被释放了。
比如:class myThread
{
public:
myThread(thread& t)
:_t(t)
{}
~myThread()
{
if (_t.joinable())
_t.join();
}
//防拷贝
myThread(myThread const&) = delete;
myThread& operator=(const myThread&) = delete;
private:
thread& _t;
};
使用方式如下:
- 每当创建一个线程对象后,就用myThread类对其进行封装产生一个myThread对象。
- 当myThread对象生命周期结束时就会调用析构函数,在析构中会通过joinable判断这个线程是否需要被join,如果需要那么就会调用join对其该线程进行等待。
例如刚才的代码中,使用myThread类对线程对象进行封装后,就能保证线程一定会被join:
int main()
{
thread t(func, 10);
myThread q(t);//使用myThread对线程对象进行封装
if (!DoSomething())
return -1;
return 0;
}
2. detach方式
detach():该函数被调用后,新线程与线程对象分离,不再被线程对象所表达,就不能通过线程对象控制线程了,新线程会在后台运行,其所有权和控制权将会交给c++运行库。同时,C++运行库保证,当线程退出时,其相关资源的能够正确的回收。detach()函数一般在线程对象创建好之后就调用,因为如果不是jion()等待方式结束,那么线程对象可能会在新线程结束之前被销毁掉而导致程序崩溃。因为std::thread的析构函数中,如果线程的状态是jionable,std::terminate将会被调用,而terminate()函数直接会终止程序。
三、互斥量库 —— mutex
1. mutex的种类
在C++11中,Mutex总共包了四个互斥量的种类:
1. std::mutex(互斥锁)
mutex是C++11提供的最基本的互斥量,该类的对象之间不能拷贝,也不能进行移动。mutex最常用的三个函数:
函数名 | 功能 |
---|---|
lock( ) | 上锁:对互斥量进行加锁 |
try_lock( ) | 尝试锁住互斥量,如果互斥量被其他线程占有,则当前线程不会被阻塞 |
unlock( ) | 解锁:释放互斥量的所有权 |
线程函数调用lock()时,可能会发生以下三种情况:
- 如果该互斥量当前没有被锁住,则调用线程将该互斥量锁住,直到调用 unlock之前,该线程一直拥有该锁;
- 如果当前互斥量被其他线程锁住,则当前的调用线程被阻塞住;
- 如果当前互斥量被当前调用线程锁住,则会产生死锁(deadlock);
线程函数调用try_lock()时,可能会发生以下三种情况:
- 如果当前互斥量没有被其他线程占有,则该线程锁住互斥量,直到该线程调用 unlock 释放互斥量;
- 如果当前互斥量被其他线程锁住,则当前调用线程返回 false,而并不会被阻塞掉;
- 如果当前互斥量被当前调用线程锁住,则会产生死锁(deadlock);
2. std::recursive_mutex(递归互斥锁)
该锁专门用于递归函数中的加锁操作。
- 如果在递归函数中使用mutex互斥锁进行加锁,那么在线程进行递归调用时,可能会重复申请已经申请到但自己还未释放的锁,进而导致死锁问题。
- 而recursive_mutex允许同一个线程对互斥量多次上锁(即递归上锁),来获得互斥量对象的多层所有权,但是释放互斥量时需要调用与该锁层次深度相同次数的unlock()。
- 除此之外,std::recursive_mutex 的特性和 std::mutex 大致相同。
3. std::timed_mutex(时间互斥锁)
比 std::mutex 多了两个成员函数,try_lock_for(),try_lock_until() 。
try_lock_for()
- 接受一个时间范围,表示在这一段时间范围之内线程如果没有获得锁则被阻塞住(与 std::mutex的 try_lock() 不同,try_lock 如果被调用时没有获得锁则直接返回 false),如果在此期间其他线程释放了锁,则该线程可以获得对互斥量的锁,如果超时(即在指定时间内还是没有获得锁),则返回 false。
try_lock_until()
- 接受一个时间点作为参数,在指定时间点未到来之前线程如果没有获得锁则被阻塞住,如果在此期间其他线程释放了锁,则该线程可以获得对互斥量的锁,如果超时(即在指定时间内还是没有获得锁),则返回 false。
4. std::recursive_timed_mutex (递归时间互斥锁)
recursive_timed_mutex就是recursive_mutex和timed_mutex的结合,recursive_timed_mutex既支持在递归函数中进行加锁操作,也支持定时尝试申请锁。
加锁演示
我们想让两个线程对同一个变量进行++操作
int x = 0;
void func(int n)
{
for (int i = 0; i < n; i++) {
x++;
}
}
int main()
{
thread t1(func, 1000);
thread t2(func, 1000);
t1.join();
t2.join();
cout << x << endl;
return 0;
}
在上面的代码中,t1线程和t2线程都对x变量进行了++操作,本质上我们想要的结果是 x = 2000;但是运行结果如下:
我们发现结果并不是2000,提醒一下,我是在vs2019下进行测试的,有可能你在运行后结果刚好是2000,这是因为数据不是很大,你可以不断的把数据加大,然后测试;
通过刚才的演示,我们发现结果不是2000,说明这两个线程在对同一个变量进行操作的时候,出现了问题;那是为什么呢?我在之前Linux的博客中有介绍过线程相关的知识,这里不细说;
首先++操作并不是原子操作,所谓原子操作就是一件事要么完成,要么就什么都不做;x++所对应的汇编代码是3句指令,两个线程在对x进行++操作的时候,由于没有外界的约束,就存在两个线程在同一时刻改变了这个变量,恰好这个x并没有发生什么实质性的变化;
这种情况下,我们就需要对这两个线程做一个约束,就是进行加锁的操作,加锁我们是在循环外面加还是再循环里面加呢?
int x = 0;
mutex mtx;
void func(int n)
{
mtx.lock();// 在循环外面加锁
for (int i = 0; i < n; i++) {
//mtx.lock();// 在循环里面加锁
x++;
//mtx.unlock();
}
mtx.unlock();
}
int main()
{
thread t1(func, 1000);
thread t2(func, 1000);
t1.join();
t2.join();
cout << x << endl;
return 0;
}
说明:针对这个案例加锁应该加在循环外面,效率跟高
注:加锁的原则:锁的粒度尽可能的小(能给5行代码加锁,就不要给10行代码加锁)
如果在循环外面加锁:
那么这个案例就失去了多线程的意义,虽然是两个线程,但由于在外面进行加锁,这两个线程就变成了并行运行(即:t1加完t2加),但是效率高;
如果在循环里面加锁:
这种方式相比上面的,效率要低一些,但也是可以的。在里面进行加锁,x++这个代码,是执行的很快的,导致两个线程频繁的申请锁和释放锁、切换上下文;
加锁的操作,应该根据实际情况,酌情选择,在安全和效率上,我们优先选择前者;
2. lock_guard和unique_lock
如下代码,在使用互斥锁时,有时候会出现一些问题,比如刚才的代码,我们只是对x进行++操作,如果你在vector容器值插入数据(push_back)时,进行加锁,万一失败了,我们知道push_back失败时会抛异常,(抛异常后续博客中有,简单的来说就是从异常的地方跳出去,后续代码不会执行)那么已经申请了互斥锁的线程,由于抛异常,导致不能释放锁,别的线程也就拿不到锁,这就导致了死锁的问题。
为了解决这样的问题,C++11采用RAII的方式对锁进行了封装,于是就出现了lock_guard和unique_lock。
mutex mtx;
void func(vector<int>& v)
{
mtx.lock();
for (int i = 0; i < 100; i++) {
v.push_back(i);
if (i == 50) {//模拟抛异常,必然出现死锁问题
return;
}
}
mtx.unlock();
}
int main()
{
vector<int> v;
thread t1(func, std::ref(v));
thread t2(func, std::ref(v));
t1.join();
t2.join();
for (auto e : v) {
cout << e << " ";
}
cout << endl;
return 0;
}
lock_guard是C++11中的一个模板类,其定义如下:
template <class Mutex>
class lock_guard;
lock_guard类模板主要是通过RAII的方式,对其管理的互斥锁进行了封装。
- 在需要加锁的地方,用互斥锁实例化一个lock_guard对象,在lock_guard的构造函数中会调用lock进行加锁。
- 当lock_guard对象出作用域前会调用析构函数,在lock_guard的析构函数中会调用unlock自动解锁,可以有效避免死锁问题。
通过这种构造对象时加锁,析构对象时自动解锁的方式就有效的避免了死锁问题。比如:
mutex mtx;
void func(vector<int>& v)
{
lock_guard<mutex> lock(mtx);
for (int i = 0; i < 100; i++) {
v.push_back(i);
if (i == 50) {//模拟抛异常,必然出现死锁问题(但我们是lock_guard,不会出现死锁)
return;
}
}
}
int main()
{
vector<int> v;
thread t1(func, std::ref(v));
thread t2(func, std::ref(v));
t1.join();
t2.join();
for (auto e : v) {
cout << e << " ";
}
cout << endl;
return 0;
}
模拟实现lock_guard
template<class Lock>
class LockGuard
{
public:
LockGuard(Lock& lock)
:_lock(mtx)
{
_lock.lock(); //加锁
}
~LockGuard()
{
_lock.unlock(); //解锁
}
LockGuard(const LockGuard&) = delete;
LockGuard& operator=(const LockGuard&) = delete;
private:
Lock& _lock;
};
unique_lock
lock_guard的缺陷:太单一,用户没有办法对该锁进行控制,因此C++11又提供了unique_lock。
与lock_gard类似,unique_lock类模板也是采用RAII的方式对锁进行了封装,并且也是以独占所有权的方式管理mutex对象的上锁和解锁操作,即其对象之间不能发生拷贝。
在构造(或移动(move)赋值)时,unique_lock 对象需要传递一个 Mutex 对象作为它的参数,新创建的 unique_lock 对象负责传入的 Mutex 对象的上锁和解锁操作。使用以上类型互斥量实例化unique_lock的对象时,自动调用构造函数上锁,unique_lock对象销毁时自动调用析构函数解锁,可以很方便的防止死锁问题。
- 加锁/解锁操作:lock、try_lock、try_lock_for、try_lock_until和unlock。
- 修改操作:移动赋值、swap、release(返回它所管理的互斥量对象的指针,并释放所有权)。
- 获取属性:owns_lock(返回当前对象是否上了锁)、operator bool(与owns_lock的功能相同)、mutex(返回当前unique_lock所管理的互斥量的指针)。
四、原子性操作库 —— atomic
多线程最主要的问题是共享数据带来的问题(即线程安全)。如果共享数据都是只读的,那么没问题,因为只读操作不会影响到数据,更不会涉及对数据的修改,所以所有线程都会获得同样的数据。但是,当一个或多个线程要修改共享数据时,就会产生很多潜在的麻烦。比如:
#include <iostream>
using namespace std;
#include <thread>
unsigned long sum = 0L;
void fun(size_t num)
{
for (size_t i = 0; i < num; ++i)
sum++;
}
int main()
{
cout << "Before joining,sum = " << sum << std::endl;
thread t1(fun, 100000);
thread t2(fun, 100000);
t1.join();
t2.join();
cout << "After joining,sum = " << sum << std::endl;
return 0;
}
上述代码中分别让两个线程对同一个变量sum进行了100000次++
操作,理论上最终sum的值应该是200000,但最终打印出n的值却是小于200000的。 (这里存在的问题之前已经提到过了)
C++98中传统的解决方式:可以对共享修改的数据可以加锁保护。
#include <iostream>
using namespace std;
#include <thread>
#include <mutex>
unsigned long sum = 0L;
std::mutex m;
void fun(size_t num)
{
for (size_t i = 0; i < num; ++i)
{
m.lock();
sum++;
m.unlock();
}
}
int main()
{
cout << "Before joining,sum = " << sum << std::endl;
thread t1(fun, 100000);
thread t2(fun, 100000);
t1.join();
t2.join();
cout << "After joining,sum = " << sum << std::endl;
return 0;
}
这里可以选择在for循环体里面进行加锁解锁,也可以选择在for循环体外进行加锁解锁。但效果终究是不尽人意的,在for循环体里面进行加锁解锁会导致线程的频繁进行加锁解锁操作,在for循环体外面进行加锁解锁会导致两个线程的执行逻辑变为串行,而且如果锁控制得不好,还容易造成死锁。
C++11中引入了原子操作类型,使得线程间数据的同步变得非常高效。如下:
原子类型名称 | 对应的内置类型名称 |
---|---|
atomic_bool | bool |
atomic_char | char |
atomic_schar | signed char |
atomic_uchar | unsigned char |
atomic_int | int |
atomic_uint | unsigned int |
atomic_short | short |
atomic_ushort | unsigned short |
atomic_long | long |
atomic_ulong | unsigned long |
atomic_llong | long long |
atomic_ullong | unsigned long long |
atomic_char16_t | char16_t |
atomic_char32_t | char32_t |
atomic_wchar_t | wchar_t |
注意: 需要用大括号对原子类型的变量进行初始化。
程序员不需要对原子类型进行加锁解锁操作,线程能够对原子类型变量互斥访问。比如刚才的代码可以改为:
#include <iostream>
using namespace std;
#include <thread>
#include <atomic>
atomic_long sum{ 0 };//或atomic_long sum = { 0 };
void fun(size_t num)
{
for (size_t i = 0; i < num; ++i)
sum ++; // 原子操作
}
int main()
{
cout << "Before joining, sum = " << sum << std::endl;
thread t1(fun, 1000000);
thread t2(fun, 1000000);
t1.join();
t2.join();
cout << "After joining, sum = " << sum << std::endl;
return 0;
}
更为普遍的,程序员可以使用atomic类模板,定义出需要的任意原子类型。
atmoic<T> t; // 声明一个类型为T的原子类型变量t
注意:
- 原子类型通常属于"资源型"数据,多个线程只能访问单个原子类型的拷贝,因此在C++11中,原子类型只能从其模板参数中进行构造,不允许原子类型进行拷贝构造、移动构造以及operator=等。
- 为了防止意外,标准库已经将atmoic模板类中的拷贝构造、移动构造、赋值运算符重载默认删除掉了。
- 原子类型不仅仅支持原子的
++
操作,还支持原子的--
、加一个值、减一个值、与、或、异或操作。
五、条件变量库 —— condition_variable
condition_variable中提供了两种函数:Wait functions(等待函数) 和 Notify functions (通知函数)
wait系列成员函数:作用就是让调用线程进行阻塞等待
//版本一
void wait(unique_lock<mutex>& lck);
//版本二
template<class Predicate>
void wait(unique_lock<mutex>& lck, Predicate pred);
- 调用第一个版本的wait函数时只需要传入一个互斥锁,线程调用wait后会立即被阻塞,直到被唤醒。
- 调用第二个版本的wait函数时除了需要传入一个互斥锁,还需要传入一个返回值类型为bool的可调用对象,与第一个版本的wait不同的是,当线程被唤醒后还需要调用传入的可调用对象,如果可调用对象的返回值为false,那么该线程还需要继续被阻塞
notify系列成员函数
- notify_one:唤醒等待队列中的首个线程,如果等待队列为空则什么也不做。
- notify_all:唤醒等待队列中的所有线程,如果等待队列为空则什么也不做。
六、用两个线程实现交替打印1-100
尝试用两个线程交替打印1-100的数字,要求一个线程打印奇数,另一个线程打印偶数
int main()
{
int n = 100;
int i = 0;
mutex mtx;
condition_variable cv;
bool flag = false;
// 偶数-先打印
thread t1([n, &i, &mtx, &cv, &flag]{
while (i < n)
{
unique_lock<mutex> lock(mtx);
// !flag是true,那么这里获取锁的时侯不会阻塞,优先运行了
cv.wait(lock, [&flag](){return !flag; });
cout << this_thread::get_id() << "->:" << i <<endl;
++i;
// 保证下一个打印运行一定是t1,也可以防止t1连续打印运行
flag = true;
cv.notify_one();
}
});
// 奇数-后打印
thread t2([n, &i, &mtx, &cv, &flag]{
while (i < n)
{
// 模拟中间某次t2时间片用完了,竞争大,排队很,多休眠了一会
/*
if (i == 50)
{
cout << this_thread::get_id() << "休眠3s" << endl;
this_thread::sleep_for(chrono::seconds(3));
}
*/
unique_lock<mutex> lock(mtx);
// flag是false的时候,这里会一直阻塞,知道flag变成true
cv.wait(lock, [&flag](){return flag; });
cout << this_thread::get_id() << ":->" << i << endl;
++i;
flag = false;
cv.notify_one();
}
});
t1.join();
t2.join();
return 0;
}