Suggestion: Read/write lock

[matthew-mcallister]

This might be too far out of scope for the project, but a reader/writer lock implementation would be a really nice addition to redis.lock. I haven't come across a proven implementation during my brief research unfortunately. An MVP probably should have the option to allow writers to block readers.

[chayim]

Thanks @matthew-mcallister for the idea. Let's see if we can noodle this one out. Do you have any interest in contributing to this - perhaps with a PR?

[matthew-mcallister]

I wouldn't mind looking into it and opening a PR. I'll have to start with some more research. Eventually someone will likely rely on such a feature in production, and since I'm no expert in this area, it will presumably need extra scrutiny before release.

[SuperCipher]

Is there any update on this?

[matthew-mcallister]

@SuperCipher I just put it on my "projects" list to do down the line when I have some time and I'm not working on something else, since it's not really a priority for me or my job. But if other people are interested in this, I could stop putting it off.

[Dreamsorcerer]

This would be useful for us too. I think one approach could be to use keyspace notifications.

Reader:

1. Check if lock is acquired (i.e. key exists).
2. If acquired, subscribe to DEL events for the lock.
3. Wait for the DEL event, then unsubscribe and continue.

Writer can just acquire the lock as usual.

If it's desired for the writer to wait on currently running readers, then maybe adding a counter to readers, then the writer can just acquire the write lock, then wait for the counter to reach 0 and proceed.

Maybe the keyspace notifications could also optimise the normal acquiring of the lock (instead of frequent polling as it currently does)?

[LeOndaz]

Thanks @matthew-mcallister for the idea. Let's see if we can noodle this one out. Do you have any interest in contributing to this - perhaps with a PR?

I do have, what do you recommend before starting?