Closed iangneal closed 1 year ago
Hi @Dahca ,
Thanks for the report. We are providing the pmdk
version for a reference implementation using pmemobj allocator, but it is not fully tested and has no implementations (such as lock initialization and garbage collection) yet we assumed in our paper. As you also see in my comments, it is a known implementation issue caused by the absence of one of the post-crash mechanisms (lock initialization) we assumed in our paper. clht_lock_initialization
was presented as a reference implementation for initializing locks if someone wants to implement post-crash mechanisms. I agree those implementations are necessary to make it properly work for actual use, but I could not find time to work on them yet.
Hey @SeKwonLee,
Thanks for the quick responses. I can also attempt to add a solution for this in the near future, but as I said in #18, I'll be slightly delayed by an upcoming deadline.
We close this issue since it is known issue included in one of the assumptions presented in our original paper.
Bug
Exposed by crashing after acquiring a lock from
clht_put
.https://github.com/utsaslab/RECIPE/blob/fc508ddfae1ca0d77cf3d3f1b73849e65c223f26/P-CLHT/include/clht_lb_res.h#L306-L312
Steps to reproduce
The second execution should run indefinitely, waiting on acquiring the lock.
Comments
I see your comments here about locking assumptions:
https://github.com/utsaslab/RECIPE/blob/fc508ddfae1ca0d77cf3d3f1b73849e65c223f26/P-CLHT/include/clht_lb_res.h#L162-L164
Does this mean this is a known issue, or does
clht_lock_initialization
just need to be added toclht_create
? I ask because it seems thatclht_lock_initialization
is called in other places, just not in the recovery procedure.