-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RecordMutex::Lock和Unlock可能有个race condition #8
Comments
https://github.com/Qihoo360/slash/blob/95c3c6313b7b360490cd5d6673f2519e48452c4f/slash/src/slash_mutex.cc#L178-L180 |
map的锁在是ref_mutex->Lock()之前被 unlock的, 理伦上还是有可能先earse + unref后又调用了Lock |
确实会。。额 |
Lock()、Unlock()一般是在同一线程中按顺序使用,现实中不会发生Unlock(key)在Lock(key)之前的情况。 |
@DavidLiuXh 我擦,老司机看slash,硬广:推荐看https://github.com/KernelMaker/rocksutil |
@KernelMaker 本来打算打Pink, 发现里面还用了slash |
@gaodq 公共接口的没法预测是不是在同一线程里, 要是同一线程应该都不用lock了吧. |
一个线程里的lock unlock操作不都应该是成对出现的吗 |
@gaodq 没错, 所以在lock unlock这个操作可能同时出现在两个thread里,理伦上还是有可能先earse + unref后又调用了Lock |
ref_mutex指向的是一个key的锁,如果是同一个key,在两个thread里操作不会有问题,因为都是先lock;如果是不同的key那更不会存在问题了,因为操作的是不同的ref_mutex |
在Unlock中 ref_mutex->Unref();中delete了这个RefMutex后, 在Lock中是不是可能调用ref_mutex->Lock()?
The text was updated successfully, but these errors were encountered: