-
Notifications
You must be signed in to change notification settings - Fork 10.3k
How to build new types of locks with clientv3? #12490
Description
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!