How to build new types of locks with clientv3?

[pllopis]

Hi,

I'm trying to build a kind of lock that isn't provided by clientv3.concurrency (at least, as far as I can see), and I'm wondering how to achieve this with the existing API.

More specifically, I want to build a type of semaphore where only clients of the same "kind" can grab the lock at a time.
For instance, imagine clients on different racks, and due to e.g. data replication strategies of the distributed system, I want clients to be able to carry out an operation only from clients of the same rack (i.e. same "kind") at a time.

I've had a look at the clientv3.concurrency package, but I was left puzzled as to how to implement a new kind of lock such as the one I just described using the existing interface. I had a look at the Mutex Lock() implementation, as I was considering using this as a template to build my own variation. But it seems that these functions use waitDeletes() and waitDelete(), which are not public. Making my own Mutex Lock, plus copying waitDeletes and waitDelete into my project could work, but definitely feels like going a complicated/wrong path at this point as it means duplicating boilerplate code.

Old versions of this project contained a contrib/recipes/ with a rwmutex.go implementation, which also rolled its own WaitEvents(), but they're since gone.

At this point I'm wondering what would be the recommended way to implement a lock like this? Am I missing any existing patterns that would allow me to build a new kind of lock more easily? Or should I roll my own the way described above?
Also, is the intention of this project to accept new PRs to increase the amount of available concurrency patterns?

Thanks in advance for your input!

[pllopis]

answering my on question: this does indeed seem the way to go, and it's not so much boilerplate as I initially thought. I've found that the etcd3 apis make this all quite neat.

I am wondering however if a collection of distributed concurrency patterns based on etcd3 already exists? I imagine that there must surely be a collective interest in maintaining a robust set of these. Is there already an ongoing effor to build this collection, whether it is in the form of recipes or a library, in this or another project?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.