锁

read lock write lock long duration lock short duration lock

回顾：

G1-G4:

G1. If a variable or parameter is declared to have type T&& for some deduced type T, that variable or parameter is a universal reference.

G2.

几年前，整理了一份rvalue相关笔记：以前的一份笔记，梳理近况时，发现某些问题还是没有弄清楚。

Universal Reference

• Q: 什么场景下需要考虑这个问题？ A：模板元编程时，需要考虑兼容各种传入参数类型时（尤其是『左值/右值』）。基本上我感觉就是为了处理完美转发问题。比如写一个工厂函数模板，需要同时兼容传入的参数是左值和右值的情况，核心点是一个右值无法用于初始化一个左值引用，c++11之前要解决这个问题，要么写很多重复偏特化模板，要么付出拷贝参数的代价。

  c++11引入右值引用之后，上述问题可以通过universal reference来解决，即传入参数是左值时，形参的类型推导为左值引用，是右值时，推导为右值引用，同时只需要提供一套模板即可。

• Q: 什么是Universal Reference? A: 形如T&&, T不含有任何的cv限定符, 且T需要被推导

  G1. If a variable or parameter is declared to have type T&& for some deduced type T, that variable or parameter is a universal reference.

background

we would set env var USE_SSE=1 when compiling Rocksdb, OTHERWISE it would always failed at linking stage where encountering errors of lack of some instructions such as: no such instruction: shlx %rdx,%rax,%rax'`. but what the fuck is USE_SSE ?

引子

很煞笔的一天，最近两次面试的试水都挂了（但之前面的两个小公司都拿到offer，小公司没有现场编程题），根因都是现场编程题不太理想。这个也不能怪别人，自己长期以来排斥刷题，觉得刷题纯度太低了，加上到目前为止就没有一次现场编程挂过。

这波有种熟悉的感觉回来了：大二参加acm预选被血虐留下的心理阴影，在那之后再也没碰过OJ。

另外，问到的一个关于LSM读写放大的优化也答得不是特别理想，因为工作上对这块的优化确实没有做，我看了下都是使用了默认的参数，更别说对compact等进行深度定制（引擎这块上不太深入，这也与工作中至今为止主要负责的模块不是这块有关）。

这是读书时一篇旧文搬运.几年后再次回顾下算法.

跳表是一种著名数据结构。

原理应该不用介绍了，rocksdb/redis内部都有使用skiplist。

相对于红黑树，它的优势我认为是实现简单，并且容易无锁化。

本文主要讨论：

实现一个简单skiplist

上一篇笔记里回顾了跳表的性质和思想，并且看了一眼rocksdb里的skiplist实现。

然后由于好奇，我自己写了一个skiplist，这里记录下。

该skiplist的特性：

• 不支持concurrent

1. 写请求batch内的多个操作是否会被拆开，为什么？
2. block-cache里的缓存项是否会因为某个sst被compact而失效？
3. event-listener的实现
4. perf-context的实现
5. ThreadLocalPtr的实现以及为什么

最近比较详细地缕了一遍公司内部另一个团队的存储产品（基于apache thrift），后简称为A。到目前为止，本团队存储产品自研的rpc框架，加上自己写过一个简单rpc框架用于rdb实例分裂，已经接触了3个rpc框架。准备在这篇文章总结下一些个人感想。

连接处理模型

• A的服务端：使用thrift-rpc的nonblock-server，连接处理模型是同步的： a. io线程在收到一个包后，会先把自己设为idle（具体点就是摘掉本线程上的可读写事件），扔给worker线程处理完成后再加回来。

• A的cli端的处理是同步的：

最近比较详细地缕了一遍公司内部另一个团队的存储产品（基于apache thrift），后简称为A。到目前为止，本团队存储产品自研的rpc框架，加上自己写过一个简单rpc框架用于rdb实例分裂，已经接触了3个rpc框架。准备在这篇文章总结下一些个人感想。

连接处理模型

• A的服务端：使用thrift-rpc的nonblock-server，连接处理模型是同步的： a. io线程在收到一个包后，会先把自己设为idle（具体点就是摘掉本线程上的可读写事件），扔给worker线程处理完成后再加回来。

• A的cli端的处理是同步的：