====== Motivation ======

Locks, mutexes, semaphores, monitors are usually associated with concurrent programming. But exclusive resource access is also needed in distributed environments, e.g. when using a micro-service architecture.

====== Locking service ======

When having multiple instances of a service, it needs to be ensured that the action is performed only by one instance.
A leader will be elected, and failure needs to be detected and dealt with. Consensus algorithm like Paxos exist.
A separate locking service could be build, which is able to manage locks. The service needs a strongly consistent datastore, which holds information about the lock (who holds it, how long) and there needs to be logic to deal with failures.

====== Implementations ======

  * Distributed locking with Zoo-Keeper: https://dzone.com/articles/distributed-lock-using
  * Hashicorp Consul: https://www.consul.io/docs/guides/semaphore.html
  * Google Chubby
  * Distributed locks with Redis: https://redis.io/topics/distlock
    * Not recommended when lock should be used for guarantee correctness (http://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html)
  * Relational database
    * Fencing tokens 
    * Linearizable writes
      * Writes should appear to be instantaneous. Once a write completes, all later reads should return the value of that write or the value of a later write. Once a read returns a particular value, all later reads should return that value or the value of a later write.