阅微堂

去掉 vim 每行结尾的 ^M

张志强 — Thu, 27 Feb 2020 08:47:58 +0100

有时候用vim打开文件，每行结尾都有一个灰色的^M。这个原因是该文件在 windows 系统上被创建。windows 的换行符是\n\r，而 unix 下的文本换行只需要\n，这个多余的\r就被显示为^M，虽然显示为两个字符，但其实是一个字符。

大多数情况下，打开这种文件，vim的状态栏会显示文件格式：utf-8[dos]，此时只需要下面命令可转为unix格式，即可删除所有的^M:

:set ff=unix

如果vim显示文件格式已经是utf-8[unix]，这时候上述命令就不管用了，说明 vim 识别类型错误，可以先把它纠正（即用dos格式打开当前文件），再变更类型：

:e ++ff=dos 
:set ff=unix

还有一种方法是字符串替换：

:%s/\r//g

注意这里是用\r而不是^M，这也是很多人不会删除^M的原因。

在 EasyMDE 里添加数学表达式支持和表格快速对齐

张志强 — Sat, 22 Feb 2020 20:48:42 +0100

最近试用了一些 markdown 编辑器，之前最有名的是 simplemde， 2017 年之后未更新，有人在此基础上做了个 easymde，现在还有一些更新。

这个东西的一个问题是不支持数学公式。幸好它的自定义能力比较强，我用Katex给它加了数学表达式的支持。

首先添加一大堆依赖：

<script src="https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script>

<link rel="stylesheet" href="https://cdn.jsdelivr.net/highlight.js/latest/styles/tomorrow.min.css">
<script src="https://cdn.jsdelivr.net/highlight.js/latest/highlight.min.js"></script>

<link href="https://cdn.bootcss.com/KaTeX/0.11.1/katex.min.css" rel="stylesheet">
<script src="https://cdn.bootcss.com/KaTeX/0.11.1/katex.min.js" ></script>

<link rel="stylesheet" href="https://unpkg.com/easymde/dist/easymde.min.css">
<script src="https://unpkg.com/easymde/dist/easymde.min.js"></script>

然后引入下面函数：

<script>
function easymdn_katex_wrap(ele, config, markedOptions) {
    markedOptions = {
        renderer: new marked.Renderer(),
        highlight: function(code, language) {
            const validLanguage = hljs.getLanguage(language) ? language : 'cpp';
            return hljs.highlight(validLanguage, code).value;
        },
        pedantic: false,
        gfm: true,
        breaks: true,
        sanitize: false,
        smartLists: true,
        smartypants: false,
        xhtml: false,
        ...(markedOptions || {}),
    };

    marked.setOptions(markedOptions);

    let customMarkdownParser = function(plainText) {
        plainText = plainText.replace(/\$\$(.*?)\$\$/g, function (match, p1) {
            return "<p class='text-center'>" 
                + katex.renderToString(p1, {displayMode: true}) + "</p>";
        }).replace(/\$(.*?[^\\])\$/g, function (match, p1) {
            return katex.renderToString(p1, {displayMode: false});
        });

        return marked(plainText);
    };

    /// align table in markdown
    let formatTable = function (table) {
        function strWidth(str) {
            var len = 0;
            for (var i = 0; i < str.length; ++i) {
                len += (str.charCodeAt(i) < 256) ? 1 : 2;
            }

            return len;
        }

        table = table.trim();
        if (!table) {
            return "";
        }

        var rows = table.split("\n").map(function (row) {
            row = row.split("|");
            row = row.map(function (col) {
                return col.trim();
            });

            return row;
        });

        var widths = Array(rows[0].length).fill(0);
        rows.forEach(function (row) {
            row.forEach(function (item, col) {
                widths[col] = Math.max(widths[col], strWidth(item));
            });
        });

        console.log(widths);

        rows = rows.map(function (row) {
            row = row.map(function (item, col) {
                if (widths[col] > 0) {
                    item = " " + item + " ".repeat(widths[col] - strWidth(item) + 1);
                }

                return item;
            }).join("|");

            return row;
        });

        return rows.join("\n");
    };

    config = {
        spellChecker: false,
        autosave: {
            enabled: false,
        },
        toolbar: [
            'bold', 'italic', 'strikethrough', 'heading-3', 'code', 'quote',
            'unordered-list', 'ordered-list', 'clean-block', 'link', 'image', '|', 'table',
        {
            name: "format_table",
            action: function (editor){
                console.log(editor);
                var selection = editor.codemirror.doc.getSelection();
                editor.codemirror.doc.replaceSelection(formatTable(selection));
            },
            className: "fa fa-align-justify",
            title: "格式化表格",
        }, 'preview', 'side-by-side', 'fullscreen', '|', 'guide',  ],


        placeholder: 'Type here...',
        tabSize: 4,
        previewRender: function(plainText, preview) { // Async method
            setTimeout(function(){
                preview.innerHTML = customMarkdownParser(plainText);
            }, 250);
        },
        ...(config || {})
    };

    return new EasyMDE(config);
}   
</script>

最后要用的时候直接调用：

<script>
var mde = easymde_katex_wrap($("#textarea"));
</script>

几点说明：

上述代码增加了highlight.js进行代码高亮。
easymde_katex_wrap 函数的第二个参数为 easymde的可选参数，可参考https://github.com/Ionaru/easy-markdown-editor#configuration。
easymde_katex_wrap 函数的第三个参数为 marked的可选参数，可参考https://marked.js.org/#/USING_ADVANCED.md#options。

上面还增加了一个按钮，可以对选中的 markdown 表格代码快速对齐。简单举个例子，如果我们选中下面的表格：

| aaaa | bbb | c
|---|-|-
|x|xxxx|xx

点击快速对齐的按钮之后，将会格式化成下面的代码：

| aaaa | bbb  | c  
| ---  | -    | -  
| x    | xxxx | xx

中信证券股权衍生品 2020 夏季 Quant 组招聘

张志强 — Thu, 13 Feb 2020 00:00:00 +0100

招聘部门：中信证券股权衍生品业务线

股权衍生品业务线是中信证券开展权益类产品交易的业务部门，其业务模式是依托中信证券的信用和资产负债表，作为产品设计者和交易对手方，面向机构和零售客户提供种类丰富的与权益资产相关的投融资产品，满足客户各项需求。

工作地：北京亮马桥中信证券总部

招聘岗位：金融科技岗

有意者请将简历寄送至 campusrecruitment@citics.com ， 2020 年 2 月 29 日之前有效。邮件和附件标题都为姓名-学校-专业，如张三-北京大学-数学。

职责：

为部门衍生品交易(如期权、互换等)提供全生命周期的系统化解决方案；
利用计算机技术提高部门业务流程的自动化水平，助力公司金融科技转型；
承担部门业务数据中台职责，对部门各项业务经营数据进行多维度分析与可视化展示；
配合搭建收益凭证产品管理平台, 串联前中后流程, 保证数据顺利流转, 为实现规模化运营打基础。

要求：

2020 年毕业的硕士、博士；
学习能力突出，编程感觉良好，工作态度严谨，不限专业或实习经历；
较强的来自工作/实习/项目的编程实践经验，熟悉 Python 等脚本语言；
较强的数理分析能力以及深入研究问题和解决问题的能力；
熟练使用 Office 软件, 要能使用宏或者简单 VBA ；
自我激励，自我驱动，持续学习。

加分项：

能够在快节奏高压力的环境下高效率的实行多任务和独立工作；
对算法、模式，架构有深入、全面的理解；
结构化思维，能够将松散的实际问题转化成可程序化解决的结构，并将其从粗略的想法推进到完全实施；
有金融市场及有关股票，衍生产品的初步知识，及对其交易定价/执行，产品生命周期的初步了解。

C++ 的多行宏定义方式

张志强 — Tue, 28 Jan 2020 00:00:00 +0100

C++的多行宏有标准定义方式，boost和folly库都采用了这种方式：

#define MACRO(X)        \
    do {                \
        X = 1;          \
        std::cout << X; \
    } while (0)

其中\用来换行，其它最关键之处为实际运行语句用do {} while (0)包起来。这是为什么呢？

如果直接定义如下：

#define MACRO1(X)        \
    X = 1;              \
    std::cout << X;

那么下面语句展开的结果可能不符预期：

int x = 0;
if (x == 0) 
    MACRO1(X);

直接用{}包起来也不行：

#define MACRO2(X)        \
    {                   \
        X = 1;          \
        std::cout << X; \
    }

它在下面语句展开会造成语法错误：

int x = 0;
if (x == 0) 
    MACRO2(X);
else 
    x = 2;

在标准定义中引入了多余的语句，但在现代编译器会自动优化掉这些语句，不会增加指令。

《新宋》完本

张志强 — Sun, 26 Jan 2020 00:00:00 +0100

从 2004 年开始连载，历时 15 年，《新宋》终于完本。实体书已出版，微信读书上也可以免费看（用免费的无限卡）。

小说分为三部分。第一部分十字，讲述如何利用穿越优势，积攒实力，进入朝堂。第二部分权柄，主要是攻伐。第三部分燕云，主要是抗辽。

《新宋》应该算网文里历史穿越小说的鼻祖。自它之后，历史穿越小说已经成为网文里很大的一个派系，但类似于《新宋》的少之又少。其根本原因在于金手指。大部分穿越小说都大开金手指，随便造个什么东西，一个月就能卖遍全国，日进万金。其它人物要么是主角附庸，要么是主角装逼的垫脚石。而《新宋》完全不一样，也在于上面两点。

其一，《新宋》的金手指开得极为有限，基本只在于第一部分，后面两部分基本没有金手指。到第三部分，已经是负向金手指，或者说给敌人和对手开了金手指。比如石越的声望，在诗词石九变、论语正义、历代政治得失、石学七书（相当于开创七个现代科学学科）、灭亡西夏、封建南海的巨大功绩下，居然还不如王安石和司马光。作为白水谭书院、讲武学堂创始人、商业推动人，石越居然无法掌控朝堂，这完全难以想象。

其二，《新宋》中的配角非常精彩，几乎没有主角的附庸。主角完全能控制的基本只有作为侍卫的侍剑。历史人物悉数登场，有名有姓的上千人。到第三部分，主要内容都是在谈人和各种利益关系，经常是连续几十页都没出现主角的名字，而主角的作用都是协调各种利益关系。

不过也因为这两点，《新宋》越到后期，越接尽历史小说，爽感越低，阅读起来更困难。到最后连燕云也没打下来，不符合绝大多数读者的期望。宋朝需要辽国抗击和管理北方蛮人的理由完全不成立。一个很简单的原因：宋朝的骑兵已经超过辽国。辽国失去燕云会奔溃也只是可能，作者笔下的西夏失去全部故土却越来越强大。

无需服务器的 TOX 通信协议

张志强 — Sat, 25 Jan 2020 00:00:00 +0100

Tox 是一个开源的实时通信协议，不需要中央服务器，提供多种跨平台的客户端。

一个简单介绍: https://www.coldl.com/1545.html。

1. Tox 的基本用法

目前 Tox 提供多种跨平台的客户端，但基本用法都类似。

客户端可以直接生成新的账号，每个账号由公钥和私钥组成，其中公钥包含在用户 ID 中，私钥则保存在设备上。用户可以备份和复制私钥文件，然后用于不同设备登录相同账号。

账号可以用密码来保护，相当于将私钥用密码加密保存。但一旦忘记密码，账号就彻底丢失了。因为这里没有一个中心服务器提供找回密码的服务。

一个用户 ID 是由 32 字节的公钥， 4 字节的 NoSpam 码， 2 字节的校验码构成。其中一个字节实际数据为 0 到 255 ，用 16 进制的可视化表示（ A 到 F 表示 10 到 15 ）有 2 位。因此实际看到的是 64 位的公钥， 8 位的 NoSpam 码和 4 位的检验码：

这里 NoSpam 也是一个精妙的设计，可以防止恶意添加好友。由于公钥一旦公布就不能随意改动，如果没有 NoSpam ，相当于个人地址被泄露。现在用户可以通过修改 NoSpam 码，改动个人地址，对方必须使用新的地址才能添加好友。新地址有 256^4 种可能性，足以防范枚举攻击。而已有的好友关系不受影响。

添加好友后，聊天功能和其它工具类似。

2. Tox 的缺陷

目前 Tox 的主要缺陷有：

不支持离线消息。
实际使用时，用户状态不准确造就更大的问题。比如对方不在线却显示在线，或者明明已登录，对方却看不到我。在手机上尤其明显。
不支持多点登录。
点对点通讯，暴露个人位置。虽然可以通过代理来缓解，普通用户无能力也无资源。而且目前的 tox 实现，只支持匿名代理。但匿名代理很容易被滥用。

其中点对点通讯带来的问题在手机上尤其严重。即使不聊天，应用也需要和所有好友不断通讯维持用户的在线状态，每个好友都需要维持一个网络连接，这使得手机应用耗电非常大。

3. Tox 通信协议

Tox 使用一系列算法来确保加密，调用了NaCI的实现libsodium，所有实现都位于c-toxcore。具体的规范在https://zetok.github.io/tox-spec/。

具体的加密算法有：

(ECDSA & DH)密钥生成和交换算法： X25519
(DEA)堆成加密算法： XSalsa20 stream cipher
(MAC)验证: Poly1305 MAC

3.1. 用户 ID 的生成

生成一个用户 ID 主要是要生成一个私钥-公钥对，具体实现使用NaCI的crypto_box_keypair函数。该函数内部使用的是 Curve25519 生成公钥和私钥密码对。

这里需要注意的是，该公钥私钥体系属于ECDSA，而不是 RSA 体系。它只能用来签名，不能用来加密解密。

用户 ID 除了公钥外，还有 4 位 NoSpam 码，这是完全随机的。检验码则是简单 XOR。

3.2. 如何发现对方 IP

Tox 是点到点直连。那么在没有中心服务器存储每个人的位置时，如何获得对方的 IP 呢？这可能是 Tox 最核心的部分了。这里面有两个最核心的组件：

DHT 分布式哈希表。DHT 里有多个节点，每个 Tox 的客户端都是一个节点。每个节点都有一个临时 DHT 地址。DHT 网络的作用是：任何人都可以通过 DHT 查询指定节点。
Onion 洋葱网络。洋葱网络连接

在这两个组件的帮助下，要想发现对方，只需要两步：

使用 Onion ，根据用户 ID 里面的公钥部分，查到好友的临时 DHT 地址。
使用 DHT ，连到指定 DHT 地址的具体节点。

由于 Onion 也构建在 DHT 的基础上，我们先看 DHT。

3.2.1. DHT 分布式哈希表

DHT 全称叫分布式哈希表(Distributed Hash Table)，是一种分布式存储方法。在不需要服务器的情况下，每个节点负责一个小范围的路由，并负责存储一小部分数据，从而实现整个 DHT 网络的寻址和存储。

Tox 也使用 DHT 网络也维护所有用户的状态。每个用户的客户端都是 DHT 网络里的一个节点。每个节点都有一个临时的公钥私钥密码对，其中公钥作为节点（或者说用户）的临时 DHT 地址。这和用户 ID 非常类似，不同的时，用户 ID 在同一用户上保存不变，甚至可以通过复制转到另外一个客户端。而节点地址则在客户端每次重启都会重新生成。

TOX DHT 的维护算法基本和https://zh.wikipedia.org/zh-hans/Kademlia一致。每个节点都用8-buckets结构维护临近节点。

当用户知道对方的 DHT 地址时，会递归查询与目标地址更近的节点，直到找到目标节点。tox 也提供 8 个引导节点，以实现第一层的递归查询。

3.2.2. Onion 洋葱网络

Onion 洋葱网络用来根据用户 ID 里面的公钥部分，查询用户的临时 DHT 地址。但它要实现的东西更多：

如果查询方已经是被查询方的好友，可以顺利查询到被查询方的好友。
如果查询方还不是被查询方的好友，此时不能暴露被查询方的位置。
不能从用户的临时 DHT 地址，暴露出该用户的公钥地址。

3.3. 如何添加好友

【未完待续】

端到端加密的技术背景

张志强 — Fri, 24 Jan 2020 00:00:00 +0100

现在越来越多的软件支持端到端加密，服务器和第三方即使获取所有网络流量，也无法查看具体数据内容，从数学和工程上提供安全性。

其中一个最简单的实现就是非对称加密。双方都持有私钥，公布公钥。发送者使用自己的私钥和对方的公钥加密，接收者使用对方的公钥和自己的私钥解密。

但在实际操作中还有很多其它考虑因素：

如果密钥泄露，历史消息能否被泄露（前向安全）。
其中接收者登录了多个设备，如何在多个终端上阅读同时确保安全性。
是否支持群聊。
支持离线消息等等。

为此，端到端通讯里涉及了一系列的加密概念。

1. forward sececy 前向安全

前向安全是指只要通讯当时的密钥没有全部泄露，只有当前的密钥泄露，历史消息仍然安全。

比如如果总是使用同一公钥密钥进行通信，一旦密钥泄露，历史消息将被一览无遗，这就不符合前向安全。

因此要想实现前向安全，通信是密钥必须要不断更换。一个最简单的方法是每次都生成新的私钥和公钥。

2. Post-Compromise security / Future Secrecy / 后向安全

后向安全是指，如果即使密钥遭到泄露，也只能使用一段时间。如果没有持续泄露，很快泄露的密钥将无法解密新的消息。

3. MAC

全称 Message Authentication Code ，就是用于生成摘要，验证消息完整性以及源身份。一个典型是HMAC。

【未完待续】

不安全信道下的 Diffie-Hellman 密钥交换协议

张志强 — Thu, 23 Jan 2020 00:00:00 +0100

迪菲－赫尔曼密钥交换（ Diffie–Hellman key exchange ，简称「D–H」）是一种安全协议。它可以让双方在完全没有对方任何预先信息的条件下通过不安全信道建立起一个密钥。这个密钥可以在后续的通讯中作为对称密钥来加密通讯内容。

1. 离散对数的数学概念

协议基于离散对数的概念：

如果$ a$是素数$ p$的一个原根，那么数值：

$$ a \mod p ， a^2 \mod p, \cdots, a^{p-1} \mod p $$

是各不相同的整数，且以某种排列方式组成了从 1 到 p-1 的所有整数。

如果对于一个整数$ b$和素数$ p$的一个原根$ a$，可以找到一个唯一的指数$i$，使得：

$$ b = a^i \mod p, 0 \leq i \leq p - 1 $$

那么指数$ i$称为$ b$的以$ a$为基数的模$ p$的离散对数。

Diffie-Hellman 算法的有效性依赖于计算离散对数的难度，其含义是：当已知大素数$ p$和它的一个原根$ a$后，对给定的$ b$，要计算 $ i$ ，被认为是很困难的，而给定$ i$ 计算$ b$ 却相对容易。

2. 具体的 Diffie-Hellman 算法

假如用户 A 和用户 B 希望交换一个密钥。取素数$ p$和整数$ a$，$ a$是$ p$ 的一个原根，公开$ a$和$ p$。

A 选择随机数$ X_A<p$，并计算$ Y_A=a^{X_A} \mod p$。
B 选择随机数$ X_B<p$，并计算$ Y_B=a^{X_B} \mod p$。

每一方都将 X 保密而将 Y 公开让另一方得到。

A 计算密钥：$ K=Y_B^{X_A} \mod p$。
B 计算密钥：$ K=Y_A^{X_B} \mod p$。

密钥的有效性：

$$K_B = Y_B^{X_A} = a^{X_BX_A} = a^{X_AX_B} = Y_A^{X_B} = K_A \mod p$$

由于$ X_A$和$ X_B$是保密的，而第三方只有$ p$, $ a$, $ Y_B$、$ Y_A$可以利用，只有通过取离散对数来确定密钥，但对于大的素数$ p$，计算离散对数是十分困难的。

3. 优势和缺陷

DH 协议可以让通信双方平等地协商密钥，而且可以很简单地扩充到多方协商。

该协议可以防止中间人偷窥，恶意中间人对数据流的截获并不会计算出双方协商出的密钥。但该协议无法完全防止中间人攻击。如果中间人仿冒 A ，和 B 协商一份密钥$ K_{AB}$；再仿冒 B 和 A 协商一份密钥$ K_{BA}$。然后 A 发送给 B 的信息用$ K_{AB}$加密，中间人截获解密后再用$ K_{BA}$加密发送给 B ，此时 B 无法意识到信息被人查看。

因此，现代密码学中， DH 协议通常配合公钥体系（ RSA 或者DSA）共同使用。协议双方会使用私钥签名，对方可以验证，从而防范中间人攻击。

在 Nginx 中使用 letsencrypt 证书实现 HTTPS

张志强 — Wed, 22 Jan 2020 00:00:00 +0100

最近在配置 matrix synapse 时，才注意到现在配置一个 https 网站已经非常简单，而且 nginx 也非常好用。

1. 生成 SSL Letsencript 证书

letsencrypt提供免费的 SSL 证书，并且操作非常简单，命令行下几条命令即可完成。

1.1. 安装`letsencrpt`

首先安装命令行工具：

sudo apt install letsencrypt -y

1.2. 生成证书

再使用下面命令即可为zhiqiang.org生成免费的 SSL 证书：

sudo certbot certonly --rsa-key-size 2048 --standalone --agree-tos --no-eff-email --email zhang@zhiqiang -d zhiqiang.org

这条命令会显示以下信息：

Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/zhiqiang.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/zhiqiang.org/privkey.pem
   Your cert will expire on 2020-04-21. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

生成的证书文件位于文件夹/etc/letsencrypt/live/zhiqiang.org/fullchain.pem下。

1.3. 常见错误

需要注意的是上面命令有可能出现下面的提示：

Problem binding to port 80: Could not bind to IPv4 or IPv6.

字面意思是所需要的 80 端口被占用。但我检查sudo netstat -ap | grep 80并没有发现 80 端口被占用。使用sudo systemctl stop nginx停止nginx后，问题解决，虽然原因仍不明确。

1.4. 设置自动更新证书

letsencript提供的证书有效期只有 90 天，因此需要定期更新证书。可以在服务器添加一个crontab定时任务来处理。由于certbot需要sudo权限，我们需先用sudo -i切换到root用户，然后输入crontab -e，添加下面的定时任务：

10 1 * */2 * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx"

添加完毕后exit可以退出root用户。

2. 使用 Nginx 配置 HTTPS 站点

有了上面的证书，就可以配置 HTTPS 站点了。nginx 的配置也比以前的 apache 简单多了。

2.1. 安装`nginx`

sudo apt install nginx

安装后的nginx位于/etc/nginx。

2.2. 添加站点

直接添加/etc/nginx/sites-enabled/zhiqiang.org文件：

# 将80端口的http服务转发到443端口https服务。
server {
       listen 80;
       server_name zhiqiang.org;
       return 301 https://$server_name$request_uri;
}

# 配置443端口的https服务
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name zhiqiang.org;

    ssl_certificate /etc/letsencrypt/live/zhiqiang.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/zhiqiang.org/privkey.pem;

    root /home/zhangzq/blog/ftp;
    index index.html index.htm;

    location /_matrix {
      proxy_pass http://127.0.0.1:8008;
      proxy_set_header X-Forwarded-For $remote_addr;
    }
}

# 可以配置很多个https服务，使用不同的端口，比如 https://zhiqiang.org:444。
server {
    listen 444 ssl;
    listen [::]:444 ssl;
    server_name zhiqiang.org;

    ssl_certificate /etc/letsencrypt/live/zhiqiang.org/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/zhiqiang.org/privkey.pem;

    location / {
      proxy_pass http://127.0.0.1:8080;
      proxy_set_header X-Forwarded-For $remote_addr;
    }
}

添加完毕之后执行测试命令：sudo nginx -t，若显示下面结果表示一切正常，如有警告或错误，需根据提示修改，最常见的错误是少写分号：

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

2.3. 启动`nginx`

下面命令可启动nginx：

sudo systemctl start nginx

下面命令可让系统在开机时自动启动：

sudo systemctl enable nginx

其它相关的还有重启：sudo systemctl restart nginx，以及停止：sudo systemctl stop nginx。

C++ 的标准异步库 std::async

张志强 — Mon, 13 Jan 2020 00:00:00 +0100

C++11 的标准异步库至少包含下面内容：

std::promise
std::future
std::packaged_task
std::async

它们的作用要从std::thread的一个示例说起：

int a = 1;
std::thread thread([a](int b) {
    return a + b;
}, 2);

thread.join();

上面这段代码会新创建一个线程来计算1 + 2。但我们没办法获取线程的计算返回值。异步库则封装了新建线程执行任务，同时获取任务返回值的操作。比如可以使用std::promise和std::future：

int a = 1;
std::promise<int> res;
std::future<int> future = res.get_future();

std::thread thread([a](int b, std::promise<int> res) {
    res.set_value(a + b);
}, 2, res);

std::cout << future.get() << std::endl;

也可以使用std::packaged_task和std::future：

int a = 1;
std::packaged_task<int(int)> task = [a](int b) {
    return a + b;
};
std::future<int> future = task.get_future();
task(2);
std::cout << future.get() << std::endl; // 2

而使用std::async可以大大简化上面的工作：

std::future<int> future3 = std::async([a](int b) {
    return a + b;
}, 2);

std::future<int> future4 = std::async([a](int b) {
    return a + b;
}, 3);

std::cout << future3.get() + future4.get() << std::endl; // 7

std::async的源代码位于https://gcc.gnu.org/onlinedocs/gcc-7.5.0/libstdc++/api/a00074_source.html，其函数实现摘抄如下：

template<typename _Fn, typename... _Args>
std::future<__async_result_of<_Fn, _Args...>> async(launch __policy, _Fn&& __fn, _Args&&... __args) {
    std::shared_ptr<__future_base::_State_base> __state;

    auto caller = std::thread::__make_invoker(std::forward<_Fn>(__fn), std::forward<_Args>(__args)...);
    if ((__policy & launch::async) == launch::async) {
        __try {
            __state = std::make_shared<__future_base::_Async_state_impl>(std::move(caller));
        }
        catch(const system_error& __e) {
            if (__e.code() != errc::resource_unavailable_try_again || (__policy & launch::deferred) != launch::deferred)
                throw;
        }
    }
    if (!__state) {
        __state = std::make_shared<__future_base::_Deferred_state>(std::move(caller));
    }
    return future<__async_result_of<_Fn, _Args...>>(__state);
}

如果lanch policy含std::launch::async，则在下面构造类中启动线程：

template<typename _BoundFn, typename _Res>
class __future_base::_Async_state_impl final : public __future_base::_Async_state_commonV2 {
public:
    explicit _Async_state_impl(_BoundFn&& __fn) 
        : _M_result(new _Result<_Res>()), _M_fn(std::move(__fn))
    {
        _M_thread = std::thread{ [this] {
            __try {
                _M_set_result(_S_task_setter(_M_result, _M_fn));
            }
            __catch (const __cxxabiv1::__forced_unwind&) {
                // make the shared state ready on thread cancellation
                if (static_cast<bool>(_M_result))
                    this->_M_break_promise(std::move(_M_result));
                    __throw_exception_again;
                }
            } 
        };
    }

    ~_Async_state_impl() { if (_M_thread.joinable()) _M_thread.join(); }

private:
    _Ptr_type _M_result;
    _BoundFn _M_fn;
}

如果有异常或者lanch policy含std::launch::deferred，不会启动线程，只是保存caller待用：

template<typename _BoundFn, typename _Res>
class __future_base::_Deferred_state final : public __future_base::_State_base
{
public:
    explicit _Deferred_state(_BoundFn&& __fn) : _M_result(new _Result<_Res>()), _M_fn(std::move(__fn))
    { }

private:
    typedef __future_base::_Ptr<_Result<_Res>> _Ptr_type;
    _Ptr_type _M_result;
    _BoundFn _M_fn;

    virtual void _M_complete_async() {
        _M_set_result(_S_task_setter(_M_result, _M_fn), true);
    }

    virtual bool _M_is_deferred_future() const { return true; }
};

【未完待续】

智能指针的辅助函数 std::make_shared 和 std::enable_shared_from_this

张志强 — Sun, 12 Jan 2020 00:00:00 +0100

前面已经提到std::shared_ptr有三个缺陷：

shared_ptr对象共用引用计数器，计数器本身需通过new放在堆上。而new会引起性能问题。
引用计数的内存区域和数据区域不一致，缓存失效导致性能问题。
编写代码不善，将导致同一个数据，绑定到了两个引用计数，从而导致双重删除。

boost::instrusive_ptr可以解决这些问题。但std::shared_ptr也提供了配套函数来试图解决。这就是std::make_shared和std::enable_shared_from_this。

1. `std::make_shared`

std::make_shared的作用是在为数据分配空间的同时，分配计数器的空间（从实际实现是反过来，在分配计数器空间的空时，多分配一块空间给数据用），让数据和计数器在连续的内存区域，对 CPU 缓存也友好。同时不用暴露原始指针，也降低了第三个问题的出现几率：

auto xp = std::make_shared<int>(1);

它的实现依赖于shared_ptr的构造函数：

template<typename _Tp, typename... _Args>
inline shared_ptr<_Tp> make_shared(_Args&&... __args) {
    typedef typename std::remove_const<_Tp>::type _Tp_nc;
    return __shared_ptr<_Tp>(_Sp_make_shared_tag(), std::allocator<_Tp_nc>(),
                            std::forward<_Args>(__args)...);
}

这里_SP_make_shared_tag是一个空的helper类，只是为了区别构造函数的不同重载。实际调用的构造函数如下：

template<typename _Alloc, typename... _Args>
__shared_ptr(_Sp_make_shared_tag __tag, const _Alloc& __a, _Args&&... __args)
    : _M_ptr(), _M_refcount(__tag, (_Tp*)0, __a, std::forward<_Args>(__args)...)
{
    void* __p = _M_refcount._M_get_deleter(typeid(__tag));
    _M_ptr = static_cast<_Tp*>(__p);
    _M_enable_shared_from_this_with(_M_ptr);
}

实际内存分配发生在_M_refcount的构造函数：

template<typename _Tp, typename _Alloc, typename... _Args>
__shared_count(_Sp_make_shared_tag, _Tp*, const _Alloc& __a, _Args&&... __args) : _M_pi(0) {
    typedef _Sp_counted_ptr_inplace<_Tp, _Alloc, _Lp> _Sp_cp_type;
    typename _Sp_cp_type::__allocator_type __a2(__a);
    auto __guard = std::__allocate_guarded(__a2);
    _Sp_cp_type* __mem = __guard.get();
    ::new (__mem) _Sp_cp_type(std::move(__a), std::forward<_Args>(__args)...);
    _M_pi = __mem;
    __guard = nullptr;
}

构造原始数据则藏在_Sp_counted_ptr_inplace构造函数中。这个类是计数器的基类，里面不光包含了计数器，也包含了数据对象：

template<typename _Tp, typename _Alloc, _Lock_policy _Lp>
class _Sp_counted_ptr_inplace final : public _Sp_counted_base<_Lp> {
    // actual data object
    struct _Impl : _Sp_ebo_helper<0, _Alloc> {
        __gnu_cxx::__aligned_buffer<_Tp> _M_storage;
    };
    _Impl _M_impl;

public:
    template<typename... _Args>
    _Sp_counted_ptr_inplace(_Alloc __a, _Args&&... __args) : _M_impl(__a) {
        allocator_traits<_Alloc>::construct(__a, _M_ptr(), std::forward<_Args>(__args)...); 
    }
}

所以make_shared将导致数据的内存空间合并到了计数器。而我们知道数据的存续期将早于计数器，这使得即使数据被销毁，如果计数器还没销毁，数据的内存空间将不会被释放！这和boost::instrusive的设计完全相反。

2. `std::enable_shared_from_this`

std::enable_shared_from_this是一种侵入式设计，和boost::instrusive差不多：

class T : public std::enable_shared_from_this {
public:
     int age;
     std::string name;
};

T* t = new T();
// 下面的shared1, shared2和weak都使用同一个计数器。
std::shared_ptr<T> shared1 = t;
// 只有t已经被一个shared_ptr托管时，shared_from_this()才有效，否则将抛出异常。
std::shared_ptr<T> shared2 = t->shared_from_this();
std::weak_ptr<T> weak = t->weak_from_this();

其中std::enable_shared_from_this的实现很简单：

template<typename _Tp>
class enable_shared_from_this
{
public:
    shared_ptr<_Tp> shared_from_this()
    { return shared_ptr<_Tp>(this->_M_weak_this); }

    shared_ptr<const _Tp> shared_from_this() const
    { return shared_ptr<const _Tp>(this->_M_weak_this); }

    weak_ptr<_Tp> weak_from_this() noexcept
    { return this->_M_weak_this; }

    weak_ptr<const _Tp> weak_from_this() const noexcept
    { return this->_M_weak_this; }

protected:
    template<typename _Tp1> 
    void _M_weak_assign(_Tp1* __p, const __shared_count<>& __n) const noexcept
    { _M_weak_this._M_assign(__p, __n); }

private:
    mutable weak_ptr<_Tp>  _M_weak_this;
};

注意这里的_M_weak_this默认没有做初始化，因此数据没有被托管时，shared_from_this()无效。但一旦做了初始化，比如执行了std::shared_ptr<int> shared1 = t时，将调用下面初始化函数：

template<typename _Yp, typename = _SafeConv<_Yp>>
explicit __shared_ptr(_Yp* __p) : _M_ptr(__p), _M_refcount(__p, typename is_array<_Tp>::type())
{
    _M_enable_shared_from_this_with(__p);
}

而_M_enable_shared_from_this_with则负责将计数器写入数据对象中：

// if _Yp base on std::enable_shared_from_this.
template<typename _Yp, typename _Yp2 = typename remove_cv<_Yp>::type>
typename enable_if<__has_esft_base<_Yp2>::value>::type _M_enable_shared_from_this_with(_Yp* __p) noexcept {
    if (auto __base = __enable_shared_from_this_base(_M_refcount, __p))
        __base->_M_weak_assign(const_cast<_Yp2*>(__p), _M_refcount);
    }
}

从实现上看，std::enable_shared_from_this效率远没有boost::instrusive_ptr高。因为侵入数据的只是计数器的指针，并不是计数器本身。

侵入式智能指针 boost::instrusive_ptr

张志强 — Sat, 11 Jan 2020 00:00:00 +0100

如果理解了侵入式容器，侵入式智能指针也很容易理解。传统的智能指针std::shared_ptr使用了和数据无关的引用计数，这带来两个问题：

引用计数要在shared_ptr对象间共享，所以它只能位于堆上。这使得每次都需要重新new一小块内存。这导致性能问题。
引用计数的内存区域和数据区域不一致，缓存失效导致性能问题。
编写代码不善，将导致同一个数据，绑定到了两个引用计数，从而导致双重删除问题。典型代码如下：

int* x = new int;
std::shared_ptr<int> x1 = x;
std::shared_ptr<int> x2 = x;

侵入式智能指针试图解决这些问题，方法也特别直接，那就是将引用计数直接塞进数据本身，和数据共存亡。从用户角度，这只需要继承boost::instrusive_ptr_base基类：

struct T : public boost::instrusive_ptr_base<T> { 
    int age;
    std::string name;
};

T* t = new T();

// 下面这么些很安全，而且速度很快！
boost::instrusive_ptr<T> x1 =t;
boost::instrusive_ptr<T> x2 =t;

我们看boost::instrusive_ptr_base的定义，其核心就是增加一个原子操作的引用计数，以及自增和自减引用计数的函数：

template<class T>
class boost::intrusive_ptr_base {
public:
    intrusive_ptr_base() : ref_count(0) {}

    friend void intrusive_ptr_add_ref(intrusive_ptr_base<T> const* p) {
        ++p->ref_count;
    }

    friend void intrusive_ptr_release(intrusive_ptr_base<T> const* p) {
        if (--p->ref_count == 0) {
            boost::checked_delete(static_cast<T const*>(s));
        }
    }

    boost::intrusive_ptr<T> self() {
        return boost::intrusive_ptr<T>((T*)this);
    }

private:
    mutable boost::detail::atomic_count ref_count;
};

接下来实际的boost::instrusive_ptr的定义就很简单了：

template<class T> 
class boost::intrusive_ptr {
public:
    intrusive_ptr(T* p, bool add_ref = true) : px(p) {
        if (px != 0 && add_ref) {
            intrusive_ptr_add_ref(px);
        }
    }

    ~intrusive_ptr() {
        if (px != 0) {
            intrusive_ptr_release(px);
        }
    }

private:
    T * px;
}

由于解决了std::shared_ptr的三个问题，boost::instrusive_ptr的效率更高。但它也有缺陷。除了侵入式设计之外，最重要的是boost::instrusive_ptr无法支持weak_ptr，从而无法解决环形引用问题。这时因为std::shared_ptr里的数据对象和计数器分离，可以有不同的生命周期。shared_ptr的引用计数里有两个计数对象，从而支持weak_ptr。

另外一个方面，std::shared_ptr也意识到了其性能问题，内部也提供机制解决这些问题，其核心便是std::make_shared和std::enable_shared_from_this。

参考：C++智能指针 3 ：内存布局（非侵入式、enable_shared_from_this & 侵入式）

侵入式容器 Boost.Instrusive

张志强 — Fri, 10 Jan 2020 00:00:00 +0100

Boost.Instrusive 是一个很有意思的实现，里面实现了很多侵入式容器，在特定环境下，可以大大提升性能。

首先我们得理解什么是侵入式，什么是非侵入式。普遍，我们认为std的容器，比如std::list都是非侵入式的。这是因为对于任何一个（支持复制或者移动的）类型T，我们都可以定义std::list<T>。当往std::list里插入一个元素时，它会分配一个节点，这个节点的结构类似于下面这个：

struct Node {
    T data;
    Node* prev;
    Node* next;
};

std::list会将要插入的元素复制到节点里。

如果T很大，那么std::list<T>将在复制时产生较大的代价。有没有一个方法可以避免复制元素呢？或者如果T是不可复制和移动的元素呢？一个直接的方法是std::list<T*>，链表里只保存元素指针，这样只复制一个指针就好了，像是解决了我们的问题。

但 Boost.Instrusive 走得更远一些。原因是，std::list<T*>在插入元素时，还是会去分配一个节点（虽然这个节点很小只有三个指针），这产生了新的内存申请！而我们知道内存申请是很慢的，应该尽量避免。Boost.Instrusive 提供的类似容器boost::instrusive::list可以做到完全不用分配节点。

听上去很神奇，但说穿了并不神秘。回到上面的节点，事实上，我们只需要原始数据类型T里面含有这两个节点指针就可以了！比如T的定义如下：

struct T {
    int age;
    std::string name;
    T* prev;
    T* next;
};

这使得boost::instrusive::list实现的链表非常简单，它只用保存首尾两个元素的地址。所有操作都无需任何额外的内存分配。示例代码如下：

template<class T>
class boost::instrusive::list {
    T* front;
    T* back;

public:
    void push_back(T& t) {
        if (back == nullptr) {
            back = front = &t;
        }
        else {
            back->next = &t;
            t.prev = back;
            back = &t;
        }
    }

    void pop_back() {
        T* top = back;
        back = back->prev;
        top->prev = nullptr;
    }
}

这要求基础数据类添加辅助元素，相当于容器「入侵」了数据，所以叫做侵入式容器。Boost.Instrusive 提供多个侵入式容器，最常用的是下面两个：

list: std::list的侵入式版本。用户数据需添加两个指针。大部分操作都是O(1)时间。
set/multiset/rbtree: std::set/std::multiset的侵入式版本，基于红黑树。用户数据需添加三个指针。大部分操作都是O(log n)。

而用户定义支持 Boost.Instrusive 的数据类，并不需要手工去添加T* prev, next之类的（前面只是示例）。库提供基类直接继承即可。比如要支持boost::instrusive::list，直接继承boost::instrusive::list_base_hook基类即可:

struct T : public boost::instrusive::list_base_hook<> {
    int age;
    std::string name;
};

该基类本身可以带模板参数，有很多细节可以定义。比如有一个有意思的基类是using auto_unlink_hook = list_base_hook<link_mode<auto_unlink>>。当用户数据使用它做基类数，当插入到链表里的数据析构时（注意链表并不保存数据，因此两者有不同的生命周期），将自动从链表里删除，从而避免在链表里访问到无效的数据。

标准库的 std::shared_ptr 是如何实现的？

张志强 — Thu, 09 Jan 2020 00:00:00 +0100

智能指针在现代 C++里用得越多。以前只知道它大致的原理，比如使用引用计数。但很多实现细节并不清楚，最直接的，它是如何实现多线程安全的？今天找了 gnu c++ library 的实现好好看了一下。

std::shared_ptr的代码位于https://gcc.gnu.org/onlinedocs/gcc-7.5.0/libstdc++/api/a15815_source.html，它基本等价于：

template <typename T>
using std::shared_ptr = std::__shared_ptr<T>;

因此我们需要去看std::__shared_ptr<T>的实现，后者位于https://gcc.gnu.org/onlinedocs/gcc-7.5.0/libstdc++/api/a00494_source.html，几乎所有的定义都位于该文件。其继承和内存结构如下：

template<typename _Tp, _Lock_policy _Lp = __default_lock_policy>
class __shared_ptr : __shared_ptr_access<_Tp, _Lp> {
    _Tp*        _M_ptr;                 // Contained pointer.
    __shared_count<_Lp>  _M_refcount;   // Reference counter.
};

这里_Lock_policy是一个枚举量，它有三个取值：

_S_single：表示为单线程适用。
_S_mutex：表示为多线程使用，并且使用thread-layer abstractions。
_S_atomic：多线程使用，使用原子操作。

而__default_lock_policy在多线程程序中一般为_S_atomic（实际值依赖于编译设置，具体定义参见https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01123.html）。

其中基类__shared_ptr_access主要是为智能指针提供*以及->等运算符，可以忽略。

其内存布局中，第一个是指针本身，这个没什么好说的。最重要的是第二个成员__shared_count，请定义如下：

template<_Lock_policy _Lp>
class __shared_count {
    _Sp_counted_base<_Lp>*  _M_pi;
public:
    __shared_count& operator=(const __shared_count& __r) noexcept {
        _Sp_counted_base<_Lp>* __tmp = __r._M_pi;
        if (__tmp != _M_pi) {
            if (__tmp != 0) __tmp->_M_add_ref_copy();
            if (_M_pi != 0) _M_pi->_M_release();
            _M_pi = __tmp;
        }
        return *this;
    }
};

这里面保存了一个了引用计数器的指针，也就是说std::shared_ptr实际布局中为两个指针，共使用 16 字节。

先看其基类本身的定义如下，它保存了两个引用计数：

_M_use_count：引用次数（std::shared_ptr指向次数）。当为 0 时，共享指针保存的元素将被删除。
_M_weak_count：弱引用次数（std::weak_ptr指向次数），如果引用次数大于 0 ，再加 1。当为 0 时，当前计数器将被删除。

template<_Lock_policy _Lp = __default_lock_policy>
class _Sp_counted_base : public _Mutex_base<_Lp> {
    _Atomic_word  _M_use_count;     // #shared
    _Atomic_word  _M_weak_count;    // #weak + (#shared != 0)

public:
    void _M_release() noexcept {
        _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_use_count);
        if (__gnu_cxx::__exchange_and_add_dispatch(&_M_use_count, -1) == 1) {
            _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_use_count);
            _M_dispose();

            if (_Mutex_base<_Lp>::_S_need_barriers) {
                __atomic_thread_fence (__ATOMIC_ACQ_REL);
            }

            _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE(&_M_weak_count);
            if (__gnu_cxx::__exchange_and_add_dispatch(&_M_weak_count, -1) == 1) {
                _GLIBCXX_SYNCHRONIZATION_HAPPENS_AFTER(&_M_weak_count);
                _M_destroy();
            }
        }
    }

    // Called when _M_weak_count drops to zero.
    virtual void _M_destroy() noexcept { delete this; }

    // Called when _M_use_count drops to zero, to release the resources
    // managed by *this.
    virtual void _M_dispose() noexcept = 0;

    void _M_add_ref_copy() { __gnu_cxx::__atomic_add_dispatch(&_M_use_count, 1); }
}

其中_M_destroy和_M_dispose都在继承类中被重新定义。不过实现中很容易看出为什么引用计数可以做到线程安全，它使用了atomic原子数据，以及很多memory barrier。

但实际引用计数指向的是继承的类，主要是_Sp_counted_deleter和_Sp_counted_ptr。

【有待完善】

标准库的互斥锁 std::mutex 是如何实现的

张志强 — Tue, 07 Jan 2020 00:00:00 +0100

看到网上有片段，提到没有必要自己实现自旋锁，因为标准库的 std::mutex 和现在的自旋锁的实现没有两样。比较好奇，翻了一些资料，试图找到答案。

在 C++里，标准库std::mutex只是一个pthread_mutex_t的封装：

class mutex {
    pthread_mutex_t _M_mutex;
public:
    mutex() { _M_mutex = PTHREAD_MUTEX_INITIALIZER; }
    ~mutex() { pthread_mutex_destroy(&_M_mutex); }
    void lock() { pthread_mutex_lock(&_M_mutex); }
    bool try_lock() { return pthread_mutex_trylock(&_M_mutex) == 0; }
    void unlock() { pthread_mutex_unlock(&_M_mutex); }
}

因此我们需要把眼光挪向pthread库的pthread_mutex_t以及相关函数。

pthread_mutex_t在 x86 下占据 32 个字节，内部布局如下：

typedef union {
  struct __pthread_mutex_s {
    int __lock;                 //!< mutex状态，0：未占用；1：占用。
    unsigned int __count;       //!< 可重入锁时，持有线程上锁的次数。
    int __owner;                //!< 持有线程的线程ID。
    unsigned int __nusers;
    int __kind;                 //!< 上锁类型。
    int __spins;
    __pthread_list_t __list;
  } __data;
} pthread_mutex_t;

其中上锁类型有下面几种取值：

PTHREAD_MUTEX_TIMED_NP ，这是缺省值，也就是普通锁。
PTHREAD_MUTEX_RECURSIVE_NP ，可重入锁，允许同一个线程对同一个锁成功获得多次，并通过多次 unlock 解锁。
PTHREAD_MUTEX_ERRORCHECK_NP ，检错锁，如果同一个线程重复请求同一个锁，则返回 EDEADLK ，否则与 PTHREAD_MUTEX_TIMED_NP 类型相同。
PTHREAD_MUTEX_ADAPTIVE_NP ，自适应锁，自旋锁与普通锁的混合。

下面我们看最关键的加锁函数pthread_mutex_lock，它的第一个参数是锁对象指针，第二个参数是上面的锁类型。如果是普通锁，它的实现就是：

pthread_mutex_lock(pthread_mutex_t* mutex, int type) {
    if (type == PTHREAD_MUTEX_TIMED_NP) {
        LLL_MUTEX_LOCK (mutex);
    }
    // else ...
}

下面我们看宏LLL_MUTEX_LOCK的实现：

# define LLL_MUTEX_LOCK(mutex) \
  lll_lock ((mutex)->__data.__lock, PTHREAD_MUTEX_PSHARED (mutex))

其中PTHREAD_MUTEX_PSHARED用来区分线程锁还是进程锁。我们可以只关心线程锁，此时第二个参数就是LLL_PRIVATE=0。而lll_lock的实现如下：

#define lll_lock(futex, private) \
  (void)                                      \
    ({ int ignore1, ignore2;                              \
       if (__builtin_constant_p (private) && (private) == LLL_PRIVATE)        \
     __asm __volatile ("cmpxchgl %1, %2\n\t"                   \
               "jnz _L_lock_%=\n\t"                   \
               ".subsection 1\n\t"                    \
               ".type _L_lock_%=,@function\n"             \
               "_L_lock_%=:\n"                    \
               "1:\tleal %2, %%ecx\n"                 \
               "2:\tcall __lll_lock_wait_private\n"           \
               "3:\tjmp 18f\n"                    \
               "4:\t.size _L_lock_%=, 4b-1b\n\t"              \
               ".previous\n"                      \
               LLL_STUB_UNWIND_INFO_3                 \
               "18:"                          \
               : "=a" (ignore1), "=c" (ignore2), "=m" (futex)     \
               : "0" (0), "1" (1), "m" (futex),           \
                 "i" (MULTIPLE_THREADS_OFFSET)            \
               : "memory");                       \

这一段是直接用汇编实现的。其核心指令是 cmpxchgl ，汇编级别的CAS（ compare and swap ）。如果 swap 不成功，则调用__lll_lock_wait_private让调度线程（进入操作系统的同优先级的任务队列末尾）。

从这里看，std::mutex的并没有加入自旋等待的实现。那么大家说的又是什么呢？其实是pthread_mutex_lock的PTHREAD_MUTEX_ADAPTIVE_NP锁方式。我们来看它的实现：

if (type == PTHREAD_MUTEX_ADAPTIVE_NP) {
    if (LLL_MUTEX_TRYLOCK (mutex) != 0) {
        int cnt = 0;
        int max_cnt = MIN (MAX_ADAPTIVE_COUNT, mutex->__data.__spins * 2 + 10);
        do {
            if (cnt++ >= max_cnt) {
                LLL_MUTEX_LOCK (mutex);
                break;
            }

            BUSY_WAIT_NOP;
        } while (LLL_MUTEX_TRYLOCK (mutex) != 0);

        mutex->__data.__spins += (cnt - mutex->__data.__spins) / 8;
    }
}

这个实现已经和folly::MicroSpinLock基本没有两样了，甚至细节处理得更好一些，比如它每次的最大尝试次数是动态的，会根据之前的尝试次数调整。

但我还是更喜欢用folly::MicroSpinLock，因为内存结构更简单（只占一个字节，而pthread_mutex_t需要 32 个字节！）， API 相比起 C 风格的 pthread 也更顺手一些。

参考文章：

https://blog.csdn.net/tlxamulet/article/details/79047717

C++ 中获取纳秒精度的时间

张志强 — Mon, 06 Jan 2020 00:00:00 +0100

主要函数是timespec_get，可参考https://zh.cppreference.com/w/c/chrono/timespec_get。

#include <time.h>

std::string time_in_nanoseconds()
{
    struct timespec ts;
    timespec_get(&ts, TIME_UTC);

    static char buff[64];
    int end = strftime(buff, sizeof buff, "%Y-%m-%d %H:%M:%S", gmtime(&ts.tv_sec));
    sprintf(buff + end, " %09ld", ts.tv_nsec);

    return buff;
}

单个位的 spinlock 实现 folly::PicoSpinLock

张志强 — Sun, 05 Jan 2020 00:00:00 +0100

之前提到单字节且为 POD 结构的自旋锁实现folly::MicroSpinLock，而folly:PicoSpinLock则只需要一个位！实现代码在https://github.com/facebook/folly/blob/master/folly/synchronization/PicoSpinLock.h。

其实现更需要 CPU 底层指令的支持。具体不多说。想说的一个有意思的地方在于，实现文件的最前面提出：

N.B. You most likely do not want to use PicoSpinLock or any other kind of spinlock. Consider MicroLock instead.

In short, spinlocks in preemptive multi-tasking operating systems have serious problems and fast mutexes like std::mutex are almost certainly the better choice, because letting the OS scheduler put a thread to sleep is better for system responsiveness and throughput than wasting a timeslice repeatedly querying a lock held by a thread that's blocked, and you can't prevent userspace programs blocking.

Spinlocks in an operating system kernel make much more sense than they do in userspace.

这里说的应该跟内核里使用自旋锁会关闭中断有关。在用户态里使用自旋锁，无法关闭中断的情况下，一旦被中断切走，自旋锁就真的在空空干等了。

C++ 中非堵塞地运行系统命令

张志强 — Wed, 01 Jan 2020 15:32:23 +0100

要在C++中运行系统命令，可以直接使用std::system函数：

std::system("make -j");

该函数会等待 make-j 执行完。要想非阻塞，可以用bash的&功能，该符号会将任务切换到背后执行，并快速返回，这样C++的程序可以立即往下继续运行：

std::system("make -j &");

上面技巧对大多数命令都够用。但有一种情况，如果我们需要在一条命令行里执行多条命令（一般用;或者&&隔开），这时候&无法很好地实现我们的意图。一种方法是把这些命令包装在同一个命令里（比如使用.sh脚本文件）。还有一种方法是另外起一个线程：

void noblock_system(const std::string& cmd) {
    std::thread thread{[cmd]() {
        std::system(cmd);
    }};

    thread.detach();
}

还有一种实现方法是使用at，指定程序在多长时间之后执行。

Folly 的 MicroSpinLock 使用方法和实现

张志强 — Tue, 31 Dec 2019 00:00:00 +0100

由 Facebook 开发和维护的 C++库 Folly 提供了自旋锁的实现folly::MicroSpinLock，代码文件地址：https://github.com/facebook/folly/blob/master/folly/synchronization/MicroSpinLock.h。

folly::MicroSpinLock小到只有一个字节，并且为POD类型，也就是说它可以保存到文件，在（共享）内存中共享！

根据 Facebook 的测试，该自旋锁单次耗时约 13.5ns ，std::mutex性能大约在 25ns ，参考的虚函数单次调用耗时约 1.7ns。

它的使用很简单，就是lock和unlock函数，也可以用std::lock_guard来自动上锁和解锁（folly提供MSLGuard的typedef）：

folly::MicroSpinLock spinlock; 

spinlock.lock();
// your work need to protect
spinlock.unlock();

{
    // 已定义typedef std::lock_guard<MicroSpinLock> MSLGuard  
    MSLGuard guard{spinlock};
    // your work need to protect
}

为了达到POD的目的，folly::MicroSpinLock只有一个uint8_t类型的成员lock_。但每次使用时，会强行转换成std::atomic对象：

std::atomic<uint8_t>* payload() noexcept {
    return reinterpret_cast<std::atomic<uint8_t>*>(&this->lock_);
}

我们细看lock的实现：

void lock() noexcept {
  detail::Sleeper sleeper;
  while (!cas(FREE, LOCKED)) {
    do {
      sleeper.wait();
    } while (payload()->load(std::memory_order_relaxed) == LOCKED);
  }
  assert(payload()->load() == LOCKED);
  annotate_rwlock_acquired(
      this, annotate_rwlock_level::wrlock, __FILE__, __LINE__);
}

这里面有三个地方需要展开说。

第一个是cas，这个是std::atomic提供的标准比较替换的原子实现：

bool cas(uint8_t compare, uint8_t newVal) noexcept {
  return std::atomic_compare_exchange_strong_explicit(
      payload(),
      &compare,
      newVal,
      std::memory_order_acquire,
      std::memory_order_relaxed);
}

这里用了对内存顺序要求最高的std::atomic_compare_exchange_strong_explicit。具体原因和对效率的影响不太清楚。

第二个是用了detail::Sleeper。最终实现了，前 4000 次检查失败时，会插入_mm_pause空指令，但 4000 次之后，将休眠 0.5 毫秒，此时将让出 CPU ，线程被切换，避免总是占住 CPU。

因为每次只插入一条pause空指令，所以 4000 次检查，不一定够。但不提供修改方式（除了改源代码）。

第三个是最后还调用了annotate_rwlock_acquired这个函数。这个用于配合线程检查工具ThreadSanitizer，检查多线程编程中是否有Data Race现象。

当用户没有开启选项时，该函数会被编译器优化掉，因此不用担心该行代码会降低性能。

Folly 的 small_vector 容器

张志强 — Sun, 29 Dec 2019 00:00:00 +0100

由 Facebook 开发和维护的 C++库 Folly 提供folly::small_vector，代码文件地址：https://github.com/facebook/folly/blob/master/folly/small_vector.h。

folly::small_vector的基本特性是，当数据较少时，它类似于静态数组，数据位于栈上，获得最佳的性能（主要是提高缓存命中率）。同时又能确保数据量超出指定容量时不会出错，此时退化为std::vector，能容纳任意长度的数据。有点类似于std::string的实现。

需留意的是，一旦退化到堆上，将不会再回到栈上。

它基本兼容std::vector的 API 以及大多数std容器算法：

folly::small_vector<int, 2> vec;
vec.push_back(0); // Stored in-place on stack.
vec.push_back(1); // Still on the stack.
vec.push_back(2); // Switches to heap buffer.
vec.pop_back();   // pop back but still on heap buffer.

folly主打性能，在small_vector里也用了不少黑魔法，否则代码不会如此晦涩难懂。主要的黑魔法有几个：

其一是支持五个模板变量，并且后面三个可以任意排序。我们看下面的官方例子：

// With space for 32 in situ unique pointers, and only using a
// 4-byte size_type.
small_vector<std::unique_ptr<int>, 32, uint32_t> v;

// A inline vector of up to 256 ints which will not use the heap.
small_vector<int, 256, NoHeap> v;

// Same as the above, but making the size_type smaller too.
small_vector<int, 256, NoHeap, uint16_t> v;

这个是依赖boost::mpl库实现的。对，folly就是依赖了boost，所以说folly直接替代boost的说法是不对的。

其二是small_vector库最大程度优化了内存布局。可以想一下，如果我们自己写这个库，估计是这样子的：

template <typename T, size_t SIZE>
struct small_vector {
  size_t size;   // 当前已有数据长度。
  T stack[SIZE];

  size_t heap_capacity;  // 堆上已分配空间长度。
  T* heap;
};

但实际实现类似于下面这个：

template <typename T, size_t SIZE, typename SIZE_TYPE>
struct small_vector {
  SIZE_TYPE size;   // 当前已有数据长度。
  union {
    T stack[SIZE];
    struct {
      SIZE_TYPE capacity;
      void* ptr;
    } heap;
  } data;
};

那small_vector如何知道目前到底用的是 stack 还是 heap 呢？答案是用size变量的最高位来存储。这也使得容器的最高长度不能超过std::numeric_limits<SIZE_TYPE>::max()的一半。

folly甚至考虑了sizeof(T[SIZE])过小的时候，此时实际实现为：

template <typename T, size_t SIZE, typename SIZE_TYPE>
struct small_vector {
  SIZE_TYPE size;
  union {
    T stack[SIZE];
    struct {
      void* ptr;
    } heap;
  } data;
};

那此时堆长度capacity放到哪里了呢？答案是放在分配的堆内存ptr的开始位置处，数据实际存放地址会往后移。基本设计逻辑是尽量少占用栈上空间，堆上无所谓。

现在内存并不紧张，因此用时间来换空间，并大大增加编程复杂性的做法，值得商酌。我自己肯定不会冒险这么写。

其三是实现中大量使用了makeGuard，这个是为了异常安全。即在makeGuard的保护范围内，一旦发生异常，markGuard被析构，其定义的函数将被调用，以清理异常情况。如果没有发生异常，dismiss()函数将被调用，取消清理行为。如下例：

small_vector(small_vector const& o) {
  auto n = o.size();
  makeSize(n);
  {
    auto rollback = makeGuard([&] {
      if (this->isExtern()) {
        u.freeHeap();
      }
    });
    std::uninitialized_copy(o.begin(), o.end(), begin());
    rollback.dismiss();
  }
  this->setSize(n);
}

工业代码的好处是考虑比较全面。自己写的代码似乎都不会考虑这些情况。因此，对大多数工作，应尽量使用成熟框架和代码。

boost库也提供了boost::container::small_vector，功能类似，但 API 更兼容std container，比如支持std::allocator。

阅微堂

去掉 vim 每行结尾的 ^M

在 EasyMDE 里添加数学表达式支持和表格快速对齐

中信证券股权衍生品 2020 夏季 Quant 组招聘

C++ 的多行宏定义方式

《新宋》完本

无需服务器的 TOX 通信协议

1. Tox 的基本用法

2. Tox 的缺陷

3. Tox 通信协议

3.1. 用户 ID 的生成

3.2. 如何发现对方 IP

3.2.1. DHT 分布式哈希表

3.2.2. Onion 洋葱网络

3.3. 如何添加好友

端到端加密的技术背景

1. forward sececy 前向安全

2. Post-Compromise security / Future Secrecy / 后向安全

3. MAC

不安全信道下的 Diffie-Hellman 密钥交换协议

1. 离散对数的数学概念

2. 具体的 Diffie-Hellman 算法

3. 优势和缺陷

在 Nginx 中使用 letsencrypt 证书实现 HTTPS

1. 生成 SSL Letsencript 证书

1.1. 安装letsencrpt

1.2. 生成证书

1.3. 常见错误

1.4. 设置自动更新证书

2. 使用 Nginx 配置 HTTPS 站点

2.1. 安装nginx

2.2. 添加站点

2.3. 启动nginx

C++ 的标准异步库 std::async

智能指针的辅助函数 std::make_shared 和 std::enable_shared_from_this

1. std::make_shared

2. std::enable_shared_from_this

侵入式智能指针 boost::instrusive_ptr

侵入式容器 Boost.Instrusive

标准库的 std::shared_ptr 是如何实现的？

标准库的互斥锁 std::mutex 是如何实现的

C++ 中获取纳秒精度的时间

单个位的 spinlock 实现 folly::PicoSpinLock

C++ 中非堵塞地运行系统命令

Folly 的 MicroSpinLock 使用方法和实现

Folly 的 small_vector 容器

1.1. 安装`letsencrpt`

2.1. 安装`nginx`

2.3. 启动`nginx`

1. `std::make_shared`

2. `std::enable_shared_from_this`