C++11 并发指南

C++11 并发指南系列
互斥锁、自旋锁、读写锁、悲观锁、乐观锁的应用场景

原子量

atomic是一个模版,那么也就意味着我们可以把自定义类型变成原子变量。但是是否任意类型都可以定义为原子类型呢?当然不是,cppreference中的描述是必须为TriviallyCopyable类型
一个比较简单的判断标准就是这个类型可以用std::memcpy按位复制,例如下面的类:

class {
    int x;
    int y;
}

这个类是一个TriviallyCopyable类型,然而如果给它加上一个虚函数,这个类便不能按位拷贝了,不满足条件,不能进行原子化。

class {
    int x;
    int y;
    virtual int add ()
    {
        return x + y;
    }
}

如果一个类型能够满足atomic模版的要求,可以原子化,它就不用进行加锁操作了,因而速度更快吗?依然不是,atomic有一个成员函数is_lock_free,这个成员函数可以告诉我们到底这个类型的原子量是使用了原子CPU指令实现了无锁化,还是依然使用的加锁的方式来实现原子操作。不过不管是否用锁来实现,atomic的使用方式和表现出的语义都是没有区别的。具体用哪种方式实现C++标准并没有做约束(除了std::atomic_flag特化要求必须为lock free),跟平台有关。

参考:C++11的原子量与内存序浅析

Memory Order

memory_order_release/memory_order_acquire

  1. 读acquire与写release。基本成对使用,来满足同步要求。
  2. 对于同一个原子量,release操作前的写入,一定对随后acquire操作后的读取可见。

memory_order_release/memory_order_consume

  1. 这个组合比release/acquire更宽松,comsume只阻止对这个原子量有依赖的操作重拍到前面去,而非像aquire一样全部阻止。
  2. 对于同一个原子变量,release操作所依赖的写入,一定对随后consume操作后依赖于该原子变量的操作可见。

memory_order_relaxed

这个选项如同其名字,比较松散,它仅仅只保证其成员函数操作本身是原子不可分割的,但是对于顺序性不做任何保证。

memory_order_seq_cst

这个内存序是各个成员函数的内存序默认选项,如果不选择内存序则默认使用memory_order_seq_cst。这是一个“美好”的选项,如果对原子变量的操作都是使用的memory_order_seq_cst内存序,则多线程行为相当于是这些操作都以一种特定顺序被一个线程执行,在哪个线程观察到的对这些原子量的操作都一样。同时,任何使用该选项的写操作都相当于release操作,任何读操作都相当于acquire操作,任何“读取-修改-写回”这一类的操作都相当于使用memory_order_acq_rel的操作。

memory_order_acquire

当前线程中该acquire operation后的load 或strore不能被重排到该acquire operation前。


memory_order_acquire

memory_order_release

当前线程中该release operation前的内存读写都不能重排到该release operation之后。


memory_order_release

memory_order_acq_rel

该acq_rel operation之前的内存读写都不能重排到该acq_rel operation之后,该acq_rel operation之后的内存读写都不能重排到该acq_rel operation之前。


memory_order_acq_rel

compare_exchange_weak

(1) 
bool compare_exchange_weak (T& expected, T val,
           memory_order sync = memory_order_seq_cst) volatile noexcept;
bool compare_exchange_weak (T& expected, T val,
           memory_order sync = memory_order_seq_cst) noexcept;
(2) 
bool compare_exchange_weak (T& expected, T val,
           memory_order success, memory_order failure) volatile noexcept;
bool compare_exchange_weak (T& expected, T val,
           memory_order success, memory_order failure) noexcept;

操作流程如下:


自旋锁实现

#include <atomic>

class SpinLock {

public:
    SpinLock() : flag_(false)
    {}

    void lock()
    {
        bool expect = false;
        // 1. 当未被其他线程锁定时,flag_为false,与期望一致,
        //      判断语句返回true,跳出循环
        //      第二个参数true会赋值给原子对象flag_
        //      falg_的旧值false赋值给expect
        // 2. 当未被其他线程锁定时,flag_为true,与期望不一致
        //      判断语句返回false
        //      falg_的旧值true赋值给expect
        while (!flag_.compare_exchange_weak(expect, true))
        {
            //这里一定要将expect复原,执行失败时expect结果是未定的
            expect = false;
        }
    }

    void unlock()
    {
        flag_.store(false);
    }

private:
    std::atomic<bool> flag_;
};

fence和同样memory order的原子操作同步效果的区别

基于atomic_thread_fence(外加一个任意序的原子变量操作)的同步和基于原子操作的同步很类似,比如最常用的,都可以形成release acquire语义,但是从上面的描述可以看出,fence的效果要比基于原子变量的效果更强,在weak memory order平台的开销也更大。

std::string* p  = new std::string("Hello");
ptr.store(p, std::memory_order_release);

以下代码具有同样效果:

std::string* p  = new std::string("Hello");
std::atomic_thread_fence(memory_order_release);
ptr.store(p, std::memory_order_relaxed);

再比如:
(1)依赖ptr1的线程永远能读到正确值,但是依赖ptr2的不一定。

std::string* p  = new std::string("Hello");
ptr1.store(p, std::memory_order_release);
ptr2.store(p, std::memory_order_relaxed);

(2)依赖ptr1和ptr2的的线程都永远能读到正确值

std::string* p  = new std::string("Hello");
std::atomic_thread_fence(memory_order_release);
ptr1.store(p, std::memory_order_relaxed);
ptr2.store(p, std::memory_order_relaxed);

我个人的建议是,如果常规的mutex锁、条件变量、future信号能满足您的设计需求,那么您完全不需要使用atomic变量。如果您决定使用atomic变量,请尽量使用默认的顺序一致性属性。
C++ memory order循序渐进(一)—— 多核编程中的lock free和memory model
C++ memory order循序渐进(三)—— 原子变量上组合应用memory order实现不同的内存序
C++ memory order循序渐进(四)—— 在std::atomic_thread_fence 上应用std::memory_order实现不同的内存序
C++11 并发指南七(C++11 内存模型一:介绍)
当我们在谈论 memory order 的时候,我们在谈论什么
理解 C++ 的 Memory Order
C++11 并发指南六( <atomic> 类型详解二 std::atomic )
浅析C++多线程内存模型
C++ 多线程与内存模型资料汇

互斥锁

互斥锁加锁失败时(当加锁失败时,内核会将线程置为「睡眠」状态,等到锁被释放后,内核会在合适的时机唤醒线程),会从用户态陷入到内核态,让内核帮我们切换线程,虽然简化了使用锁的难度,但是存在一定的性能开销成本。
那这个开销成本是什么呢?会有两次线程上下文切换的成本:

  1. 当线程加锁失败时,内核会把线程的状态从「运行」状态设置为「睡眠」状态,然后把 CPU 切换给其他线程运行;
  2. 接着,当锁被释放时,之前「睡眠」状态的线程会变为「就绪」状态,然后内核会在合适的时间,把 CPU 切换给该线程运行。

线程的上下文切换的是什么?当两个线程是属于同一个进程,因为虚拟内存是共享的,所以在切换时,虚拟内存这些资源就保持不动,只需要切换线程的私有数据、寄存器等不共享的数据。
上下切换的耗时有大佬统计过,大概在几十纳秒到几微秒之间。

thread

std::thread对象不可复制,不可移动,因此下面for (auto e : threads)处会导致编译不过,需改为引用for (auto& e : threads)

int main()
{
    vector<thread> threads;
    for (int i = 0; i < 10; i++) {
        threads.push_back(thread(threadfun, i));
    }

    cout << "10 threads ready to race..." << endl;

    for (auto e : threads) {
        e.join();
    }
}

条件变量

条件变量是并发程序设计中的一种控制结构。
多个线程访问一个共享资源(或称临界区)时,不但需要用互斥锁实现独享访问以避免并发错误,在获得互斥锁进入临界区后还需要检验特定条件是否成立:
(1)、如果不满足该条件,拥有互斥锁的线程应该释放该互斥锁,把自身阻塞(block)并挂到(suspend)条件变量的线程队列中
(2)、如果满足该条件,拥有互斥锁的线程在临界区内访问共享资源,在退出临界区时通知(notify)在条件变量的线程队列中处于阻塞状态的线程,被通知的线程必须重新申请对该互斥锁加锁。
使用条件变量做并发控制时,某一时刻阻塞在一个条件变量上的各个线程应该在调用wait操作时指明同一个互斥锁,此时该条件变量与该互斥锁绑定;否则程序的行为未定义。条件变量必须与互斥锁配合使用,其理由是程序需要判定某个条件(condition或称predict)是否成立,该条件可以是任意复杂。

std::condition_variable

wait函数:调用线程会被阻塞,直到条件被满足。
1、void wait (unique_lock<mutex>& lck);
在线程被阻塞时,该函数会自动调用 lck.unlock() 释放锁,使得其他被阻塞在锁竞争上的线程得以继续执行。另外,一旦当前线程获得通知(notified,通常是另外某个线程调用 notify_* 唤醒了当前线程),wait() 函数也是自动调用 lck.lock(),使得 lck 的状态和 wait 函数被调用时相同。
2、template <class Predicate> void wait (unique_lock<mutex>& lck, Predicate pred);
设置了 Predicate,只有当pred 条件为 false 时调用 wait() 才会阻塞当前线程,并且在收到其他线程的通知后只有当pred 为 true时才会被解除阻塞。因此第二种情况类似以下代码:while (!pred()) wait(lck);
cplusplus condition_variable::wait

wait函数 描述
wait 没有超时,没有返回值
wait_for 有超时限制,超时数为相对时间;返回值是:std::cv_status::timeout、cv_status::no_timeout
wait_until 有超时限制,超时数为绝对时间;返回值是:std::cv_status::timeout、cv_status::no_timeout

notify函数:

notify函数 描述
notify_one 唤醒一个被阻塞的线程,注意:哪一个线程被唤醒是不确定的。
notify_all 唤醒所有被阻塞的线程。
mutex g_mutex;
condition_variable g_cond;
bool g_ready;

void threadfun(int id)
{
    unique_lock<mutex> lock(g_mutex);
    while (!g_ready) {
        cout << "thread id: " << id << " wait for ready" << endl;
        g_cond.wait(lock);
    }

    cout << "thread id: " << id << " is ready" << endl;
}

void notify()
{
    unique_lock<mutex> lock(g_mutex);
    cout << "notify all threads" << endl;
    g_ready = true;
    g_cond.notify_all();    
}

int main()
{
    vector<thread> threads;
    for (int i = 0; i < 10; i++) {
        threads.push_back(thread(threadfun, i));
    }

    cout << "10 threads ready to race..." << endl;
    notify();

    for (auto& e : threads) {
        e.join();
    }
}

参考:C++ 并发编程(三):条件变量(Condition Variable)

信号量

C++ 并发编程(六):信号量(Semaphore)

自旋锁实现

使用C++11原子量实现自旋锁

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 213,864评论 6 494
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,175评论 3 387
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 159,401评论 0 349
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,170评论 1 286
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,276评论 6 385
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,364评论 1 292
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,401评论 3 412
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,179评论 0 269
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,604评论 1 306
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,902评论 2 328
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,070评论 1 341
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,751评论 4 337
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,380评论 3 319
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,077评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,312评论 1 267
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 46,924评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 43,957评论 2 351

推荐阅读更多精彩内容