RecordMutex::Lock和Unlock可能有个race condition about slash HOT 10 CLOSED

https://github.com/Qihoo360/slash/blob/95c3c6313b7b360490cd5d6673f2519e48452c4f/slash/src/slash_mutex.cc#L178-L180
如果是最后一个引用就从records_中删除了
在Lock里面也就不会找到这个ref_mutex了

from slash.

map的锁在是ref_mutex->Lock()之前被 unlock的, 理伦上还是有可能先earse + unref后又调用了Lock

from slash.

确实会。。额

from slash.

Lock()、Unlock()一般是在同一线程中按顺序使用，现实中不会发生Unlock(key)在Lock(key)之前的情况。

from slash.

@DavidLiuXh 我擦，老司机看slash，硬广：推荐看https://github.com/KernelMaker/rocksutil

from slash.

@KernelMaker 本来打算打Pink, 发现里面还用了slash

from slash.

@gaodq 公共接口的没法预测是不是在同一线程里, 要是同一线程应该都不用lock了吧.

from slash.

一个线程里的lock unlock操作不都应该是成对出现的吗

from slash.

@gaodq 没错, 所以在lock unlock这个操作可能同时出现在两个thread里,理伦上还是有可能先earse + unref后又调用了Lock

from slash.

ref_mutex指向的是一个key的锁，如果是同一个key，在两个thread里操作不会有问题，因为都是先lock；如果是不同的key那更不会存在问题了，因为操作的是不同的ref_mutex

from slash.