There's two variants I've observed with the term "distributed locking", which this article kind of gets at, though IMO not enough to make it clear to someone who also needs to read a section called "What's a lock".<p>Most of the time, when people talk about a "distributed lock", the emphasis is on the fact that the <i>clients</i> are distributed. You can set up a Redis server, and lots of different hosts can contact it and hit the SETNX message to see if some key is locked.<p>But then other folks would say, that's not distributed at all - because the redis server everyone's hitting SETNX on is a single point of failure. It's the <i>servers</i> that need to be distributed. That's a harder task, because the servers need to coordinate on whether or not key "X" is truly available or not in an atomic way, and that's the "consensus algorithm" thing that doozerd and I've also heard Zookeeper does, which I can only start to imagine how that works.<p>Based on the DynamoDB docs at <a href="http://docs.amazonwebservices.com/amazondynamodb/latest/developerguide/WorkingWithDDItems.html#WorkingWithItemsConditionalUpdate" rel="nofollow">http://docs.amazonwebservices.com/amazondynamodb/latest/deve...</a> it seems like conditional updates work across distributed replicas, though it's only implied.
For those working with Azure, you can take a lease on a blob to manage concurrency:<p><a href="http://blog.smarx.com/posts/managing-concurrency-in-windows-azure-with-leases" rel="nofollow">http://blog.smarx.com/posts/managing-concurrency-in-windows-...</a><p>It also has high availability, lease expiration timeouts etc.