C++ 并发(4) unique_lock,读写锁以及递归锁

简介

本文介绍C++ 并发中使用的其他类型的锁,包括unique_lockshared_lock, 以及recursive_lock等。shared_lockunique_lock比较常用,而recursive_lock用的不多,或尽可能规避用这种锁。

unique_lock

unique_locklock_guard基本用法相同,构造时默认加锁,析构时默认解锁,但unique_lock有个好处就是可以手动解锁。这一点尤为重要,方便我们控制锁住区域的粒度(加锁的范围大小),也能支持和条件变量配套使用,至于条件变量我们之后再介绍,本文主要介绍锁的相关操作。

1
2
3
4
5
6
7
8
9
10
//unique_lock 基本用法
std::mutex mtx;
int shared_data = 0;
void use_unique() {
//lock可自动解锁,也可手动解锁
std::unique_lock<std::mutex> lock(mtx);
std::cout << "lock success" << std::endl;
shared_data++;
lock.unlock();
}

我们可以通过unique_lockowns_lock判断是否持有锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
//可判断是否占有锁
void owns_lock() {
//lock可自动解锁,也可手动解锁
std::unique_lock<std::mutex> lock(mtx);
shared_data++;
if (lock.owns_lock()) {
std::cout << "owns lock" << std::endl;
}
else {
std::cout << "doesn't own lock" << std::endl;
}

lock.unlock();
if (lock.owns_lock()) {
std::cout << "owns lock" << std::endl;
}
else {
std::cout << "doesn't own lock" << std::endl;
}
}

上述代码输出

1
2
owns lock
doesn't own lock

unique_lock可以延迟加锁

1
2
3
4
5
6
7
8
9
 //可以延迟加锁
void defer_lock() {
//延迟加锁
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);
//可以加锁
lock.lock();
//可以自动析构解锁,也可以手动解锁
lock.unlock();
}

那我们写一段代码综合运用owns_lockdefer_lock

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
//同时使用owns和defer
void use_own_defer() {
std::unique_lock<std::mutex> lock(mtx);
// 判断是否拥有锁
if (lock.owns_lock())
{
std::cout << "Main thread has the lock." << std::endl;
}
else
{
std::cout << "Main thread does not have the lock." << std::endl;
}

std::thread t([]() {
std::unique_lock<std::mutex> lock(mtx, std::defer_lock);

// 判断是否拥有锁
if (lock.owns_lock())
{
std::cout << "Thread has the lock." << std::endl;
}
else
{
std::cout << "Thread does not have the lock." << std::endl;
}

// 加锁
lock.lock();

// 判断是否拥有锁
if (lock.owns_lock())
{
std::cout << "Thread has the lock." << std::endl;
}
else
{
std::cout << "Thread does not have the lock." << std::endl;
}

// 解锁
lock.unlock();
});
t.join();
}

上述代码回依次输出, 但是程序会阻塞,因为子线程会卡在加锁的逻辑上,因为主线程未释放锁,而主线程又等待子线程退出,导致整个程序卡住。

1
2
Main thread has the lock.
Thread does not have the lock.

lock_guard一样,unique_lock也支持领养锁

1
2
3
4
5
6
7
8
9
10
11
12
//同样支持领养操作
void use_own_adopt() {
mtx.lock();
std::unique_lock<std::mutex> lock(mtx, std::adopt_lock);
if (lock.owns_lock()) {
std::cout << "owns lock" << std::endl;
}
else {
std::cout << "does not have the lock" << std::endl;
}
lock.unlock();
}

尽管是领养的,但是打印还是会出现owns lock,因为不管如何锁被加上,就会输出owns lock

既然unique_lock支持领养操作也支持延迟加锁,那么可以用两种方式实现前文lock_guard实现的swap操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
//之前的交换代码可以可以用如下方式等价实现
int a = 10;
int b = 99;
std::mutex mtx1;
std::mutex mtx2;

void safe_swap() {
std::lock(mtx1, mtx2);
std::unique_lock<std::mutex> lock1(mtx1, std::adopt_lock);
std::unique_lock<std::mutex> lock2(mtx2, std::adopt_lock);
std::swap(a, b);
//错误用法
//mtx1.unlock();
//mtx2.unlock();
}

void safe_swap2() {

std::unique_lock<std::mutex> lock1(mtx1, std::defer_lock);
std::unique_lock<std::mutex> lock2(mtx2, std::defer_lock);
//需用lock1,lock2加锁
std::lock(lock1, lock2);
//错误用法
//std::lock(mtx1, mtx2);
std::swap(a, b);
}

大家注意一旦mutexunique_lock管理,加锁和释放的操作就交给unique_lock,不能调用mutex加锁和解锁,因为锁的使用权已经交给unique_lock了。

我们知道mutex是不支持移动和拷贝的,但是unique_lock支持移动,当一个mutex被转移给unique_lock后,可以通过unique_ptr转移其归属权.

1
2
3
4
5
6
7
8
9
10
11
12
//转移互斥量所有权
//互斥量本身不支持move操作,但是unique_lock支持
std::unique_lock <std::mutex> get_lock() {
std::unique_lock<std::mutex> lock(mtx);
shared_data++;
return lock;
}

void use_return() {
std::unique_lock<std::mutex> lock(get_lock());
shared_data++;
}

锁的粒度表示加锁的精细程度,一个锁的粒度要足够大,保证可以锁住要访问的共享数据。

同时一个锁的粒度要足够小,保证非共享数据不被锁住影响性能。

unique_ptr则很好的支持手动解锁。

1
2
3
4
5
6
7
8
9
void precision_lock() {
std::unique_lock<std::mutex> lock(mtx);
shared_data++;
lock.unlock();
//不设计共享数据的耗时操作不要放在锁内执行
std::this_thread::sleep_for(std::chrono::seconds(1));
lock.lock();
shared_data++;
}

共享锁

试想这样一个场景,对于一个DNS服务,我们可以根据域名查询服务对应的ip地址,它很久才更新一次,比如新增记录,删除记录或者更新记录等。平时大部分时间都是提供给外部查询,对于查询操作,即使多个线程并发查询不加锁也不会有问题,但是当有线程修改DNS服务的ip记录或者增减记录时,其他线程不能查询,需等待修改完再查询。或者等待查询完,线程才能修改。也就是说读操作并不是互斥的,同一时间可以有多个线程同时读,但是写和读是互斥的,写与写是互斥的,简而言之,写操作需要独占锁。而读操作需要共享锁。

要想使用共享锁,需使用共享互斥量std::shared_mutex,std::shared_mutex是C++17标准提出的。
C++14标准可以使用std::shared_time_mutex,

std::shared_mutexstd::shared_timed_mutex 都是用于实现多线程并发访问共享数据的互斥锁,但它们之间存在一些区别:

  1. std::shared_mutex
* 提供了 `lock()`, `try_lock()`, 和 `try_lock_for()` 以及 `try_lock_until()` 函数,这些函数都可以用于获取互斥锁。
* 提供了 `try_lock_shared()` 和 `lock_shared()` 函数,这些函数可以用于获取共享锁。
* 当 `std::shared_mutex` 被锁定后,其他尝试获取该锁的线程将会被阻塞,直到该锁被解锁。
  1. std::shared_timed_mutex
* 与 `std::shared_mutex` 类似,也提供了 `lock()`, `try_lock()`, 和 `try_lock_for()` 以及 `try_lock_until()` 函数用于获取互斥锁。
* 与 `std::shared_mutex` 不同的是,它还提供了 `try_lock_shared()` 和 `lock_shared()` 函数用于获取共享锁,这些函数在尝试获取共享锁时具有超时机制。
* 当 `std::shared_timed_mutex` 被锁定后,其他尝试获取该锁的线程将会被阻塞,直到该锁被解锁,这与 `std::shared_mutex` 相同。然而,当尝试获取共享锁时,如果不能立即获得锁,`std::shared_timed_mutex` 会设置一个超时,超时过后如果仍然没有获取到锁,则操作将返回失败。

因此,std::shared_timed_mutex 提供了额外的超时机制,这使得它在某些情况下更适合于需要处理超时的并发控制。然而,如果不需要超时机制,可以使用更简单的 std::shared_mutex

C++11标准没有共享互斥量,可以使用boost提供的boost::shared_mutex

如果我们想构造共享锁,可以使用std::shared_lock,如果我们想构造独占锁, 可以使用std::lock_gurad.

我们用一个类DNService代表DNS服务,查询操作使用共享锁,而写操作使用独占锁,可以是如下方式的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
class DNService {
public:
DNService() {}
//读操作采用共享锁
std::string QueryDNS(std::string dnsname) {
std::shared_lock<std::shared_mutex> shared_locks(_shared_mtx);
auto iter = _dns_info.find(dnsname);
if (iter != _dns_info.end()) {
return iter->second;
}

return "";
}

//写操作采用独占锁
void AddDNSInfo(std::string dnsname, std::string dnsentry) {
std::lock_guard<std::shared_mutex> guard_locks(_shared_mtx);
_dns_info.insert(std::make_pair(dnsname, dnsentry));
}
private:
std::map<std::string, std::string> _dns_info;
mutable std::shared_mutex _shared_mtx;
};

QueryDNS 用来查询dns信息,多个线程可同时访问。
AddDNSInfo 用来添加dns信息,属独占锁,同一时刻只有一个线程在修改。

递归锁

有时候我们在实现接口的时候内部加锁,接口内部调用完结束自动解锁。会出现一个接口调用另一个接口的情况,如果用普通的std::mutex就会出现卡死,因为嵌套加锁导致卡死。但是我们可以使用递归锁。

但我个人并不推荐递归锁,可以从设计源头规避嵌套加锁的情况,我们可以将接口相同的功能抽象出来,统一加锁。下面的设计演示了如何使用递归锁

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
class RecursiveDemo {
public:
RecursiveDemo() {}
bool QueryStudent(std::string name) {
std::lock_guard<std::recursive_mutex> recursive_lock(_recursive_mtx);
auto iter_find = _students_info.find(name);
if (iter_find == _students_info.end()) {
return false;
}

return true;
}

void AddScore(std::string name, int score) {
std::lock_guard<std::recursive_mutex> recursive_lock(_recursive_mtx);
if (!QueryStudent(name)) {
_students_info.insert(std::make_pair(name, score));
return;
}

_students_info[name] = _students_info[name] + score;
}

//不推荐采用递归锁,使用递归锁说明设计思路并不理想,需优化设计
//推荐拆分逻辑,将共有逻辑拆分为统一接口
void AddScoreAtomic(std::string name, int score) {
std::lock_guard<std::recursive_mutex> recursive_lock(_recursive_mtx);
auto iter_find = _students_info.find(name);
if (iter_find == _students_info.end()) {
_students_info.insert(std::make_pair(name, score));
return;
}

_students_info[name] = _students_info[name] + score;
return;
}
private:

std::map<std::string, int> _students_info;
std::recursive_mutex _recursive_mtx;
};

我们可以看到AddScore函数内部调用了QueryStudent, 所以采用了递归锁。

但是我们同样可以改变设计,将两者公有的部分抽离出来生成一个新的接口AddScoreAtomic.

AddScoreAtomic可以不适用递归锁,照样能完成线程安全操作的目的。

总结

本文介绍了unique_lock,共享锁,递归锁等的使用,较为全面的介绍了这几种锁的使用场景和潜在风险。

视频链接

https://space.bilibili.com/271469206/channel/collectiondetail?sid=1623290

源码链接

https://gitee.com/secondtonone1/boostasio-learn