Skip to content

How to build new types of locks with clientv3? #12490

@pllopis

Description

@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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions