记一个关于std::unordered_map并发访问的BUG
前言
刷题刷得头疼，水篇blog。这个BUG是我大约一个月前，在做15445实现lock_manager的时候遇到的一个很恶劣但很愚蠢的BUG，排查 + 摸鱼大概花了我三天的时间，根本原因是我在使用std::unordered_map做并发的时候考虑不周。但由于这个BUG无法在我的本地复现，只能提交代码后再gradescope上看到执行日志，而且打印的日志还不能太多，因为gradescope的执行比较慢，打印日志如果稍微多加一点就会报TIMEOUT，所以着实让我抓狂了一段时间。最后的解决也很突然，非常有戏剧性，可以考虑拿来水点东西。感觉自己写blog很拖刷leetcode和背八股的节奏，所以找到实习前可能写不了太多了。
功能描述
15445 Project4要求我们为bustub添加并发访问控制，实现tuple粒度的strict 2PL。简单来说，一个RID表示着一个tuple在磁盘上的位置，因此可以唯一标识tuple；一个事务就是一个线程。事务会并发的对这些tuple进行读写访问，因此必须要引入lock来对访问进行同步，而这个Project要求我们将lock的粒度设定为tuple。为了实现这一点，bustub设定了一个单例的LockManager（但其实现方法并不是单例的），要求任何事务在访问某个RID之前，都要向这个事务申请锁。如果事务进行的是读访问操作，要调用LockManager的lock_shared()方法申请S-LOCK(共享锁，或者说读锁)，否则操作就是写操作，要调用lock_exclusive()方法申请X-LOCK(独占锁，或者说是写锁)；如果事务已经获取了S-LOCK，希望在不释放S-LOCK的情况下将锁升级为X-LOCK，则要调用lock_upgrade方法。此外，由于strict 2PL只能保证serializable Schedule，但无法保证不存在死锁，因此LockManager还需要实现死锁检测功能（但这不是本篇blog的重点）。LockManager的声明如下：
class LockManager {
enum class LockMode { SHARED, EXCLUSIVE, UPGRADE };
enum class RIDLockState { UNLOCKED, S_LOCKED, X_LOCKED };
class LockRequest {
public:
LockRequest(txn_id_t txn_id, LockMode lock_mode)
: txn_id_(txn_id), lock_mode_(lock_mode), granted_(false), aborted_(false) {}
txn_id_t txn_id_;
LockMode lock_mode_;
bool granted_;
bool aborted_;
};
class LockRequestQueue {
public:
LockRequestQueue() = default;
LockRequestQueue(const LockRequestQueue &rhs) = delete;
LockRequestQueue operator=(const LockRequestQueue &rhs) = delete;
// DISALLOW_COPY(LockRequestQueue);
RIDLockState state_;
std::mutex queue_latch_;
std::list<LockRequest> request_queue_;
std::condition_variable cv_; // for notifying blocked transactions on this rid
bool upgrading_ = false;
};
public:
/**
* Creates a new lock manager configured for the deadlock detection policy.
*/
LockManager() {
enable_cycle_detection_ = true;
cycle_detection_thread_ = new std::thread(&LockManager::RunCycleDetection, this);
LOG_INFO("Cycle detection thread launched");
}
~LockManager() {
enable_cycle_detection_ = false;
cycle_detection_thread_->join();
delete cycle_detection_thread_;
LOG_INFO("Cycle detection thread stopped");
}
/*
* [LOCK_NOTE]: For all locking functions, we:
* 1. return false if the transaction is aborted; and
* 2. block on wait, return true when the lock request is granted; and
* 3. it is undefined behavior to try locking an already locked RID in the same transaction, i.e. the transaction
* is responsible for keeping track of its current locks.
*/
/**
* Acquire a lock on RID in shared mode. See [LOCK_NOTE] in header file.
* @param txn the transaction requesting the shared lock
* @param rid the RID to be locked in shared mode
* @return true if the lock is granted, false otherwise
*/
bool LockShared(Transaction *txn, const RID &rid);
/**
* Acquire a lock on RID in exclusive mode. See [LOCK_NOTE] in header file.
* @param txn the transaction requesting the exclusive lock
* @param rid the RID to be locked in exclusive mode
* @return true if the lock is granted, false otherwise
*/
bool LockExclusive(Transaction *txn, const RID &rid);
/**
* Upgrade a lock from a shared lock to an exclusive lock.
* @param txn the transaction requesting the lock upgrade
* @param rid the RID that should already be locked in shared mode by the requesting transaction
* @return true if the upgrade is successful, false otherwise
*/
bool LockUpgrade(Transaction *txn, const RID &rid);
/**
* Release the lock held by the transaction.
* @param txn the transaction releasing the lock, it should actually hold the lock
* @param rid the RID that is locked by the transaction
* @return true if the unlock is successful, false otherwise
*/
bool Unlock(Transaction *txn, const RID &rid);
/**
* Checks if the graph has a cycle, returning the newest transaction ID in the cycle if so.
* @param[out] txn_id if the graph has a cycle, will contain the newest transaction ID
* @return false if the graph has no cycle, otherwise stores the newest transaction ID in the cycle to txn_id
*/
bool HasCycle(txn_id_t *txn_id);
/** @return the set of all edges in the graph, used for testing only! */
std::vector<std::pair<txn_id_t, txn_id_t>> GetEdgeList();
/** Runs cycle detection in the background. */
void RunCycleDetection();
private:
std::unordered_map<txn_id_t, std::vector<txn_id_t>> BuildTxnRequestGraph();
std::mutex latch_;
std::atomic<bool> enable_cycle_detection_;
std::thread *cycle_detection_thread_;
/** Lock table for lock requests. */
std::unordered_map<RID, LockRequestQueue> lock_table_;
/** Waits-for graph representation. */
std::unordered_map<txn_id_t, std::vector<txn_id_t>> waits_for_;
};
目前你只需要知道这个，为了同步多个线程（事务）的并发访问，线程会调用单例的LockManager中的lock_shared、lock_exclusive、lock_upgrade方法来获取锁，而锁的粒度是RID级别的就可以了。Project4 Part1的要求就是让我们实现上述三个方法。
设计与实现
具体的实现思路不难。我们先看一下LockManager的核心数据结构lock_table_，它实现了从RID到LockRequestQueue的映射，所有的事务在为某个RID申请lock时，必须将自己的请求构建一个LockRequest结构，插入到这个RID对应的LockRequestQueue里面，等待自己的请求被执行。图例如下：
本图中共有5个RID，理所应当有5个LockRequestQueue，这里为了简便起见我只画了其中的两个。上图中有四个事务（1，2，7，4）申请RID 1的锁，三个事务（3，2，1）申请RID 4的锁，请求到来的顺序、授予锁的顺序都是FIFO。由于RID 1的前三个请求都是S-LOCK，因此这把S-LOCK可以被授予给三个事务，而第四个事务（txn 4）的X-LOCK请求则被阻塞；
能画出这个图之后，相应的代码也不难实现了，这里我以伪代码的形式给出lock_shared的逻辑，lock_exclusive和lock_upgrade的逻辑都很类似，故不再给出，我所想讨论的BUG也在下面的代码里面：
bool LockManager::LockShared(Transaction *txn, const RID &rid) {
// Assertions for transaction state, isolation level and so on.
......
// BUG IS HERE!!!!!!
latch_.lock();
if (lock_table_.find(rid) == lock_table_.end()) {
// INSERTION MAY HAPPENDS HERE!
lock_table_[rid].state_ = RIDLockState::UNLOCKED;
}
// block other txns' visit on this rid，then we could saftly release latch_
std::unique_lock lk(lock_table_[rid].queue_latch_);
latch_.unlock();
// BUG IS HERE!!!!
LockRequest req = MakeRequest(txn->id, LOCK_SHARED);
lock_table_[rid].queue_.emplace_back(req);
auto req_iter = --lock_table[rid].queue_.end();
// waiting on condition_variable
while (wait(lock_table_[rid].queue_.cv_, lk)) ....
// Success, return
lk.unlock();
return true; // unlock the queue
}
lock_table_是一个std::unordered_map<RID, LockRequestQueue>，最开始的时候是空的，当出现一个新的RID时，会向这个unordered_map中添加一对新的 (RID, LockRequestQueue)的Pair。这是一个对unordered_map的写操作，而unordered_map并不是线程安全的，如果多个线程同时调用lock_shared去获取同一个RID的锁，而这个RID之前并不在lock_table_里，那么lock_table可能就会并发的插入同一个RID，这是非常危险的操作！！！我们必须避免这一情景，通常的方法是在可能引入插入的操作之前，获取latch_来保证单线程对lock_table_的访问操作：
// BUG IS HERE!!!!!!
latch_.lock();
if (lock_table_.find(rid) == lock_table_.end()) {
// INSERTION MAY HAPPENDS HERE!
lock_table_[rid].state_ = RIDLockState::UNLOCKED;
}
// block other txns' visit on this rid，then we could saftly release latch_
std::unique_lock lk(lock_table_[rid].queue_latch_);
latch_.unlock();
正如前文所述，由于operator []的使用可能会引入插入操作，因此这里我用latch_.lock()来隔绝其他线程对lock_table_的访问操作，这样可以避免多个线程对同一个RID同时进行插入操作的情景，当lock_table_[rid].state_ = RIDLockState::UNLOCKED;这行代码执行完毕后，这个RID的KV Pair已经存放在了这个unordered_map里面，然后我们拿到更细粒度的锁lock_table_[rid].queue_latch_，就可以释放掉latch_了，因为虽然后续的代码会访问lock_table_里的LockRequestQueue，但由于对应的RID均已经存在，因此这些操作应该看做是对lock_table_的读操作；虽然这个过程中会有新的RID插入，但不应该会对这些已经存在的RID产生影响（这里是我的第一个疏忽），因此无需关注。而那些针对LockRequestQueue的读写操作，由更加细粒度的锁LockRequestQueue.queue_latch_来提供同步，而其在latch_释放之前就已经被获取了，因此也不存在并发问题。
可以看到，这段代码是非常stupid的，因为当初为了写的快一点，我大量的使用了lock_table_[rid]来获取LockRequestQueue的引用，而operator []的操作并不是常量级的，这会引入非常多的开销（本意是测试通过之后再修改）。更重要的是这里是我的第二个疏忽，正是前后这两个疏忽造成了BUG。
BUG产生情景
在完成编码后我在本地跑了上千次测试，都可以完美PASS测试样例，但当我把代码提交到gradescope时却失败了，提示某些请求一直没有得到调度导致超时了。于是我在代码里加了点小trick，把调度失败时lock_table_的状态打印出来，于是产生了下面的日志:
先解释一下日志的输出。一个RID可以由一个二元组（page_num, slot_num）唯一表示，一个请求可以由三元组（txn_id, is_granted, lock_type）表示。我希望通过前文所述的二元组和三元组展示一下LockManager中锁调度的状态。上图中（txn 5, granted, S-LOCKED）表示事务5申请了RID(9, 9)的S-LOCK，且lock_manager已经将S-LOCK授权给了它。
注意到这个日志里有两个 RID(1, 1)，且它们的hashval是一模一样的，这说明std::unordered_map中出现了两个同样的键！。我后面又多次提交代码查看lock_table_的状态，但都获得了类似的结果，即std::unordered_map中总是会有两个相同的键，或者说，拥有同样的hasval的键被分到了两个bucket中，而我们通过下标访问lock_table_[rid]时，至多只能访问到其中的一个bucket，因此也只有这个bucket中的LockRequest可能被调度，而另一个bucket由于无法被访问到，因此其中的请求就可能永远都不会被调度了，这就导致了测试代码的超时。
我们知道，std::unordered_map通过Key获取对应的Value的规则是首先计算这个Key对应的hashval % bucket_num获取得到K-V对所在的bucket，虽然不同的Key会有不同的hashval，但他们可能会有相同的hashval % bucket_num，因此可能会被放入到同一个bucket中；为了从bucket中找到唯一的K-V对，又需要调用operator ==来找到唯一的目标Key；因此发现这个BUG后，我第一个想法就是RID的实现可能存在问题，于是去仔细查看了RID的operator ()方法和operator ==的实现，然后打消了这个念头。其实前文中我也提到了，我在日志中打印了RID对应的hashval，两个键的hashval都是一样的，却在不同的bucket中，这种情景基本不可能是operator ()方法和operator ==实现错误所能触发的、
【世界名画之：我代码错了，肯定是XXX的问题】
然后我又考虑是不是因为我前面试图降低锁粒度的方法存在问题，但用纸笔模拟了多种情景、又拿状态机之类的理论推导了一下，最终也宣告了我的怀疑破产。
这样一来我的思路就完全断掉了，于是我希望能获取到更多的这个BUG产生时的程序上下文信息。由于测试代码只涉及到了10个RID，而这种情况出现时，lock_table_的size会膨胀到11，因此这个时机可以作为一个排查BUG、获取当前lock_table_状态的切入点，因此我又往自己的代码里添加了一系列的逻辑，边打印日志边准备捕获这个瞬间，但测试代码又被TIMEOUT了，因为gradescope的执行速度比较慢，打印太多日志会导致超时，拿不到我想要的东西。
这样一时间我的调试就陷入了僵局，我猜不到这个BUG产生的可能原因，无法在本地复现这个BUG，甚至无法通过日志的方式获取到更多的信息。
BUG的解决
这个BUG的解决也很富有戏剧性，大概有两天我的思路没有进展，直到第二天晚上偶然打开cppreference时注意到了std::unordered_map的一个之前没注意到的细节：rehash。最初始时，std::unordered_map最初一般只有7个bucket，但随着插入量的增长，同一个bucket中的元素越来越多，越来越多的时间会被花费在bucket内部的线性查找上，因此std::unordered_map会在适当时机进行扩容操作，增添bucket的数量，并将之前的k-v pair重新分配到其对应的桶中。
https://en.cppreference.com/w/cpp/container/unordered_map
我自己写了一点测试代码了解rehash的行为后，猜测可能是并发访问下rehash造成了std::unordered_map的undefined行为，但这种想法一旦成立，也就意味着我前文中降低锁粒度所思考的逻辑存在着严重的问题。验证方法也很简单，在lock_table_创建时，把桶的数量开到足够大，这样就不会出现rehash的情景了：
LockManager() {
enable_cycle_detection_ = true;
cycle_detection_thread_ = new std::thread(&LockManager::RunCycleDetection, this);
// reserve enough buckets to avoid rehash
lock_table_.reserve(100);
LOG_INFO("Cycle detection thread launched");
}
修改后再次提交到gradescope，顺利通过。这样基本石锤了时rehash导致lock_table中出现了两个相同的key；
BUG的分析
当然，我不能使用这种投机取巧的方法去过测试，我又重看了前面的lock_shared方法，很快发现了问题，这里我换一批注释：
bool LockManager::LockShared(Transaction *txn, const RID &rid) {
......
latch_.lock();
if (lock_table_.find(rid) == lock_table_.end()) {
// INSERTION AND REHASH MAY HAPPENDS HERE!
lock_table_[rid].state_ = RIDLockState::UNLOCKED;
}
std::unique_lock lk(lock_table_[rid].queue_latch_);
latch_.unlock();
LockRequest req = MakeRequest(txn->id, LOCK_SHARED);
// IF REHASH AND THIS LINE IS RUNNING AT THE SAME TIME, WHAT WILL HAPPEN ?
lock_table_[rid].queue_.emplace_back(req);
auto req_iter = --lock_table[rid].queue_.end();
// AND WHAT MAY HAPPEND HERE ???
while (wait (lock_table_[rid].queue_.cv_, lk)) ....
lk.unlock();
return true; // unlock the queue
}
错误已经很明显了，我在插入LockRequest前，使用了operator []来获取对应的LockRequestQueue的引用，本意是认为新的RID的插入并不会影响这一过程，但如果在operator []执行的过程中发生了rehash，那么 bucket_num的值就会发生改变（应该是从7变为11），而这个过程中，同一个hashval就可能被送到不同的bucket中，因此就产生了undefined behaviour。
那么这个BUG该如何解决呢？再次阅读cpp reference我们可以得知，rehash不会导致引用或者指针失效，因此我们可以在持有latch_的时候，直接获取到对应的LockRequestQueue的引用，以后只通过这个引用来访问LockRequestQueue，伪代码如下：
bool LockManager::LockShared(Transaction *txn, const RID &rid) {
......
latch_.lock();
if (lock_table_.find(rid) == lock_table_.end()) {
// INSERTION AND REHASH MAY HAPPENDS HERE!
lock_table_[rid].state_ = RIDLockState::UNLOCKED;
}
// acquire the reference of LockRequestQueue；
LockRequestQueue &queue = lock_table_[rid];
latch_.unlock();
// rehash does not invalid reference queue, so it's safe here.
std::unique_lock lk(queue.queue_latch_);
LockRequest req = MakeRequest(txn->id, LOCK_SHARED);
queue.queue_.emplace_back(req);
auto req_iter = --queue.queue_.end();
while (wait (queue.cv_, lk)) ....
lk.unlock();
return true; // unlock the queue
}
还剩下一个问题：在rehash的过程中，引用是否会失效？我个人查了查相关资料，没有找到对应的讨论情况。虽然我个人认为引用不会失效，但很明显我们不应该依靠这种侥幸心理来写代码，后续重构的时候我会像一个更好地方法来解决这个问题。
总结
std::unordered_map<Key, Value>是一个无法保证线程安全的数据结构，我们必须自己来处理它的并发访问。并发访问可以支持单个进程的写操作，或者多个进程的并发读操作。一般情况下我们可以把对Value的写操作，看做是一个对std::unordered_map<Key, Value>的读操作，因为这个操作并不改变Key与Value的映射关系。operator[]是一个十分需要小心使用的方法，因为它既可能对应一个读操作，也可能对应一个写操作，如果这个方法触发了插入行为，那么其中的元数据就会被修改，如果装载引子接近了上限值时还可能触发rehash，因此operator []不应该并发的调用。
这算是我个人遇到的最难受的BUG之一了，既没法在本地复现，又没法得到更多的信息。个人非常大的失误是不了解std::unordered_map的行为，并且在BUG定位的时候没能跳出逻辑圈。实际上，试图降低锁粒度对我这种经验很少的鶸来说，是非常危险的行为，因此我个人十分不建议在缺少全局分析、缺乏经验、没有足量的测试的情况下写并发代码，能单机解决它不香嘛(