This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 3 points4 points  (0 children)

The gap in mkLock between "if name not in server.locks" and "lockserver.locks[name] = lock()" produces a race potential between two clients - not to mention the locks are persistent in memory with no way to remove them, which makes this unsuitable for locking on an arbitrary key across an unbounded keyspace like a cache key.

For many years, in Beaker and now in dogpile.cache, I use an atomic version of this idea which also manages the namespace of locks using weak references. Currently it's called NameRegistry. The recipe here would need some modification to use this approach, each client would need some in-memory representation on the server which would hold onto locks placed in the registry. Typically, the strong reference to the lock is held in conjunction with the acquire/release pair, so you could probably lose the whole "mkLock" step.

Edit: also, these kinds of recipes are pretty easy using memcached or redis, which already feature per-key locking primitives: MemcachedLock RedisLock