Samuel's Blogs

In concurrency, a race condition is anything where the outcome depends on the relative ordering of execution of operations on two or more threads;

因为race condition一般来说都是时间敏感(timing-sensitive)的，所以如果直接debug的话经常就无法复现

避免race condition

主要有三种方法避免race condition

1. 使用锁之类的机制

2. 更改数据结构以实现无锁并发

3. 将对数据结构的更新作为一个事务(transaction)

   好像有相关的术语software transactional memory (STM)，可以了解一下？

可以通过定义operator()来使一个对象变成可调用对象，从而可以作为thread的构造函数的参数来使用

1
2
3
4
5
6
7
8
9
10
11

class background_task
{
public:
    void operator()() const
    {
        do_something();
        do_something_else();
    }
};
background_task f;
std::thread my_thread(f);

C++标准每三年制定一次
11, 14, 17

并发方式

主要有两种并发方式

1. task swichting
2. genuine concurrency

实验室分享(二)

基本上就是把gnu的make的manual读了一遍，然后记录了一些自认为比较重要/经常用到的东西

代码变成可执行文件，叫做编译。对于一般的C文件，一般有以下过程

1
2
3
4

# 编译生成.o文件
cc -c main.c
# 链接生成可执行文件 main
cc main.o -o main

实在是看不太下去，而且似乎并没有学到什么，也就没有做笔记

建议直接看一篇中文博客，似乎就是这个章节的翻译

这篇主要讲的讲的是作者不断完善SocialCalc的过程以及遇到的一些问题的解决方法
可以认为是协同文档的一种

简单记录一下：

1. 通过发送操作本身而不是整个表的内容，来减少带宽的使用量，并且允许在不稳定的网络下恢复之前的操作

2. 使用PocketIO中间件来使得一些不支持socket的老版本浏览器也可以兼容

3. 当一个文档使用了很久然后一个新的成员添加进来的时候，可能会导致新的成员需要在本地执行非常多的指令才可以达到其他成员目前的状态，并且在此期间无法进行任何的修改
   通过snapshot的机制来进行弥补，比如说每执行100条指令，server就会从所有的client中拉取其目前的最新文档，并且将最新的文档保存在log中，之后新加入的成员就只需要拉取最近的一次snapshot并执行至多99条指令就可以达到最新的状态。但是也会有新的问题，比如说服务器无法对不同版本的文档进行判别，而且如果出现恶意的(malicious)的快照，后续的所有的新加入的成员都有可能拿到错误的文档。

   其实可以发现导致上述问题的原因就是因为服务器没有执行js(command也就是指令)的能力，所以后来作者用Node.js重写了server，使得客户端有了执行js的能力，但也因此损失了一部分的并发能力以及延迟。

4. 因为server每次执行一个命令都需要在本地对html进行渲染，就导致CPU直接被卡死，之前使用的jsdom效率不够高，所以作者用LiveScript写了一个简单的DOM来实现HTML的export。上述问题得到了解决

5. 使用W3C的Web Worker API使得代码可以利用多核CPU的性能优势

由于最近看的一本书(TPOSA)中的第一章讲的就是Chromium，所以突然就想下载一下源码，然后又想要不就试试编译一下？

首先官方有一个指导文档

可能不会列出所有的可能性，但是还是稍微记录一下我本人的具体步骤以及踩过的坑吧

时间：2020/12/17
Mac: macbook pro late 2013 15’
Mac系统版本: 10.15.7 (19H15)
Chromium版本(hash): a7361976c2c0be7139f4de8eb8844702a198f0cf

参考的博客

• macOS 10.15 下载及编译 Chromium
• mac上面进行chromium编译