Implement lock for multiple watchers: exists or roll my own?

[WilliamDEdwards]

Case:

• A key is watched by clients A/B/C.
• When the key is updated, all clients should do work.
• Only one client should do work simultaneously.

The solution seems obvious:

On receiving a watch event, all watchers try to acquire a named lock.

But is it safe to try acquiring a lock multiple times in a very short time span, or at exactly the same time?

If not, each client could sleep for $random seconds. If client A acquires the lock on second .1, and clients B and C try to acquire the lock .1 seconds later, the lock should be exclusive and acquired in order.

Does etcd ship some high-level construct that combines multiple watchers + distributed lock? Or should I roll my own solution with these primitives?

[acrosby]

Wish someone with technical knowledge of the etcd locks would comment. It has been our experience that use of the locks are problematic in most practical applications.

[WilliamDEdwards]

We've been using etcd locks for over a year now, which works well.