本文是对 Jeff Preshing 的 Double Checked Locking Is Fixed in C++ 11 笔记。

0x00 传统实现

因为 synchronization 只需要在实例第一次创建时保证；此后（ instance != nullptr 时）都不需要锁来保证 synchronization。

在第一次判断实例为空和上锁之间存在一个 potential race，因此上锁后需要再一次判断实例是否为空。

这也是 double checked 的来由。

所以一个传统但并不100%正确的 DCLP 实现如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class Singleton {
public:
    static Singleton* GetInstance()
    {
        if (instance == nullptr) {
            std::lock_guard<std::mutex> lock(mtx);
            if (instance == nullptr) {
                instance = new Singleton();				// <-- key point
            }
        }

        return instance;
    }

private:
    // omit explicit static field initialization.
    static std::mutex mtx;
    static Singleton* instance;
};

这基本是早起 C++ DCLP 的实现架子。

0x01 问题：内存乱序以及为什么锁帮不了忙

语句

1

instance = new Singleton();	

在 C++ 中实际上等效于

1
2
3

tmp = operator new(sizeof(Singleton));  // step 1: allocate memory via operator new
new(tmp) Singleton;                     // step 2: placement-new for construction
instance = tmp;                         // step 3: assign addr to instance

注意：其中除了分配内存是固定第一步之外，构造对象和赋值内存地址的生成代码顺序是由编译器自己决定。这里的顺序只是一种可能性。

近段有相当一部分时间在熟悉和练习 ASIO。

练习过程中发现 ASIO 中如何使用&管理 buffer 是新手大概率会遇到的问题。

结合最近几个 practice demo，稍微简单总结了一下使用经验：

0x00

const_buffer 和 mutable_buffer 是两个 fundamental buffer classes。二者的区别在语义上表达的很明显了。

实现上二者提供的接口非常一致，除了一个面向 const void*，另一个面向 void*。这点可以从 ctor 和 data() 中看出。

另外，为了和 C++ 现有的 const cast semantics 保持一致，一个 mutable_buffer 对象可以 implicitly converted to const_buffer。

首先承认这个标题乍看之下很像 troll，但真的不是 troll；“避免使用”总的来说更接近 whenever possible 的意思。

另外，这篇 post 面向的主要是偏底层的、直接使用 system calls 或其 runtime wrapper（glibc）的开发者，最典型的比如 C/C++ 开发者。

其他语言的开发者通常因为要么 runtime “屏蔽”了这部分内容（如 Java）；要么 runtime 自身对这部分做了较大的抽象/改造（如 Golang），因此很难对此 post 提到的各种观点/做法产生共鸣。

FYI：自从工作后中文写作能力一直在退化，因此这篇文章如果存在语句不通顺或者用词不当的地方，烦请见谅。

0x00 背景回顾：什么是 signal？

signal 源自 Unix，后来成为 POSIX 标准的一部分，现在则被几乎所有的 *nix 系统支持。

signal 本质上是一种通讯机制，用于系统在某个事件（event）发生时通知某个进程（或线程）。

Concurrency

A Lock-Free… Linear Search?

其实是 Jeff Preshing 的 Acquire and Release Fences Don’t Work the Way You’d Expect 这篇文章的笔记。

拿 learn-asio 这个项目练手时发现一个问题：learn-asio 依赖了 KBase，这两个项目都是我用 anvil 进行托管的，所以两个项目的 cmake 目录里各自有一份 compiler_*.cmake。

因为 compiler_*.cmake 提供的函数 apply_common_compiler_property_to_target() 默认使用了非常严格的属性，导致构建 asio 练手工程出现很多 warning 和静态分析的错误，所以为了省事我把 learn-asio 的这个函数做了宽松化处理。

0x00 Background

考虑到 ASIO 的相当一部分组件（subset）已经进入了 C++ 20 Networking TS，未来再经过一些小调整之后成为标准库的一员基本板上钉钉。

那么提前熟悉一下 ASIO 也不是什么坏事，毕竟没准等到 C++ 23 的时候，coroutine, networking, executor 啥的都已经很完备了，谁都可以用 C++ 实现一些性能不差的 server-end 代码了（比如 RPC 框架？）。

不过和使用 Boost 类似，使用 ASIO 作为依赖库也不是一件容易的事情；毕竟自 modern C++ 元年至今都8年了，CMake 还在成为 de facto building system 的道路上挣扎，广泛接受的包管理依然不见踪影…

0x01 ASIO-CMake Wrapper

陈年老账就不再扯了，得益于 CMake 3.2 开始提倡的 taget-based properties 和 CMake 3.11 开始提供的 FetchContent module，我花了一些时间实现了一个基于 FetchContent 的 asio-cmake wrapper。