Hello, you can easily mount a lock that auto-releases itself after some timeout using the new (2.6.13) extended SET command (see http://redis.io/commands/set) or simply a Lua script.
Since the jobs we're locking can have somewhat inconsistent times we're actually using an implementation where the tasks can get a lock with a time limit and can extend their lock so long as they still have it, so they do potentially auto-release.
Even given this, bad lock timing (not that likely) or a crash (more likely) could let inconsistency in.
Shrugs
Like I said, my problem is not really Redis's. If I can't trust everything that uses a lock not to crash 99.99% of the time I should really be looking at our jobs and not at Redis.
Even then, though, it's probably more a matter of me not trusting things than it is said things not actually being trustworthy.
We're about to open source a similar deal (redis-based "soft guarantee" mutexes) -- ours is written in Python and mostly used as a way to coordinate (very frequent) parallel task execution a la CountDownLatch, so 100% reliable exclusion in the face of failure isn't critical.
I'd be interested to hear about your implementation if you can share (email is HN username at gmail.com)
Even given this, bad lock timing (not that likely) or a crash (more likely) could let inconsistency in.
Shrugs
Like I said, my problem is not really Redis's. If I can't trust everything that uses a lock not to crash 99.99% of the time I should really be looking at our jobs and not at Redis.
Even then, though, it's probably more a matter of me not trusting things than it is said things not actually being trustworthy.