Generic locking mechanism. #41

wants to merge 5 commits into

3 participants


Based on the "BPOP" commands this adds a generic locking command (similar to advisory locks in mysql).

Basic usage is

C1: GRAB sesskey.AE123 0

C1: OK

C2: GRAB sesskey.AE123 0

C1: RELEASE sesskey.AE123

C1: OK

C2: OK

Also if a client disconnects all of it's locks are released.

A client MAY lock multiple keys.

Some things I don't like about how it's implemented right now.
I've kludged in some "reserving" of the Key in (doing a dbAdd of a 0 value) and checking to make sure it's a REDIS_STRING (so as to not conflict with BPOP). However this has a few issues.

the lock does nothing to prevent working with the actual key (and really shouldn't). So another client can delete and readd the key as a REDIS_LIST and screw things up.

Ideally I need to create a separate blocking system from the BPOP blocks, or adjust how they are stored so that BPOP will ignore GRAB blocks and GRAB will ignore BPOP locks.

Any thoughts on this are very welcome.



I think WATCH and SETNX are already two primitives where it's trivially possible to do this without need for further commands. And we are minimalist ;)



How exactly do I use those two command to accomplish the same result? As it does not seem to do the same thing at all?


I've redone the implementation so it doesn't conflict at all with BPOP, so a GRAB/RELESAE and BPOP can operate simultaneously on the same key..



Composing locks out of primitives have been researched multiple times since this issue first came up.

Current best practices are:

@mattsta mattsta closed this May 30, 2014
@JackieXie168 JackieXie168 pushed a commit that referenced this pull request Sep 16, 2014
@danielmewes danielmewes Add a test which runs in Valgrind DRD and Helgrind.
Closes #41.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment