Concurrency

Memory Barriers Are Like Source Control Operations

C++ 的 std::unique_ptr 有个神奇的特性：如果使用默认的 deleter（即使用 operator delete），或者 non-capturing lambda 作为 deleter，则有

1

sizeof(std::unique<T>) == sizeof(void*);

即整个对象的内存布局和 trivial pointer 一致，没有额外的开销。

这个特性的背后就是 compress-pair；这个设施能够在某个元素是一个 empty class 时避免为其分配内存。

注：这里假设你知道什么是 EBO，以及为什么会有 EBO。

这里自己动手实现一个 compressed pair：

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
45
46
47
48

template<typename Tx, typename Ty, bool = std::is_empty<Tx>::value>
struct CompressedPair : Tx {
    Ty second;

    template<typename T>
    explicit CompressedPair(T&& t)
        : Tx(),
          second(std::forward<T>(t))
    {}

    template<typename T, typename U>
    CompressedPair(T&& t, U&& u)
        : Tx(std::forward<T>(t)),
          second(std::forward<U>(u))
    {}

    Tx& get_first() noexcept
    {
        return *this;
    }

    const Tx& get_first() const noexcept
    {
        return *this;
    }
};

template<typename Tx, typename Ty>
struct CompressedPair<Tx, Ty, false> {
    Tx first;
    Ty second;

    template<typename T, typename U>
    CompressedPair(T&& t, U&& u)
        : first(std::forward<T>(t)),
          second(std::forward<U>(u))
    {}

    Tx& get_first() noexcept
    {
        return first;
    }

    const Tx& get_first() const noexcept
    {
        return first;
    }
};

因为 EBO 是实现的核心，而父类的构造顺序先于子类的任何成员，上面将 Tx 作为可被优化的成员。

过去两周抽了点时间给 KBase::CommandLine 做了一个变更，重新设计了 parameter 和 switch 的用户访问接口。

Concurrency

Roll Your Own Lightweight Mutex

核心是 Jeff Preshing 大牛的两篇文章

• Roll Your Own Lightweight Mutex

0x00

前段时间专门抽空做了一个小工具，也就是这里要讲的主题：anvil

一开始做 anvil 的动力很简单：某次尝试体验一下 Linux SignalFD 功能时想直接使用 ezio 的 EventLoop 作为基础事件循环，同时项目使用 cmake 管理。

为了省事，我直接从 ezio 的项目里抠出来 CMakeLists.txt 和几个自己写的 .cmake 文件，就地修改。

但事实证明哪怕这样，改动量也不小，原因大体是因为：cmake 里（非函数内定义的）变量作用域是全局的，通过 fetch-content 功能引入的依赖在 add_subdirectory() 后的模块里也能看到上一层定义的变量，因此为了防止一些控制型变量发生冲突，我都在前面加上了对应的模块前缀。

所以我面对的就是一大坨变量名的更换，以及少部分声明/属性的调整。

考虑到大部分的文件内容都是可以模板化的，而手动“实例化”不仅费事还很容易出错，所以我就很自然地萌生了写一个工具自动化这个过程的想法。

0x01

在经过一两天的短暂思考后，我大致确定了这个工具的定位和需要实现的基本目标，总结起来有三个核心点：

1. 辅助 cmake 而不是试图替代它或深度封装
2. 内建一个轻量型的依赖管理功能
3. 配置化的生成 & 构建流程

首先，第一点是重中之重。

Programming Languages

Destructors that throw

C++ 11之后的 destructor 默认是 noexcept，如果有 active exception 逃逸出 dtor 会直接触发 std::terminate()，即使外部有 catch handler。可以用 noexcept(false) 显式关闭。

因为 stack unwinding 是可以嵌套的，一个精心设计的场合下（见文中例子），可以做到多个 active exception 不在一个层次里，因此也不会触发 double-exception situation。

Who calls std::terminate?

an exception leaves out from main function

an exception leaves out from initial function of a thread

an exception leaves out from dtor (since c++ 11 with noexcept guarantee)