Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Am I understanding correctly that wait-free writes are not supported? #13

Open
stevenroose opened this issue May 3, 2023 · 2 comments

Comments

@stevenroose
Copy link

I was about to start using this package because I have a single-writer, multi-reader setup where the write operation cannot wait for readers, so a traditional RwLock or Mutex can be annoying. The description says that evmap has "lock-free writes" but I don't see how that would work. Both flush and refresh will block the writer until the readers are done.

I would want a situation where writers can freely add operations without every having to wait and as soon as there are no more readers, the readers' side is updated. But on the readers' time, not on the writer's time.

It seems like with "lock-free writes" you are intending to say "writes don't prevent new reads", it seems ambiguous as I took it to mean "writes don't need to wait for a lock".

@stevenroose
Copy link
Author

Maybe there could be something like a try_refresh or try_flush method, but that would not be ideal as it would mean that if it fails, the refresh can only happen next time try_refresh would be called.

A set_ready_to_refresh would be better. But I was under the impression that was what flush would do. But it seems not to be the case.

@jonhoo
Copy link
Owner

jonhoo commented Aug 6, 2023

You're technically correct, which is the best kind of correct! One could argue that writes to the map are wait free, because, well, the pure write operation is, but once you take into account having to also expose them to readers, then they're not wait free any more. I think updating the description is a good idea, if you want to submit a PR?

Adding a try_refresh and try_flush makes a lot of sense to me! Happy to take a look at a PR if you have a chance.

As for the larger feature of essentially "scheduling" a refresh to happen whenever it becomes possible, this one is actually quite tricky. The big question is what to do with modifications to the map between when refresh returns and when the readers have actually moved on and one of the maps is available for writes. You could stick them in the oplog, but handling the logic of that oplog then becomes significantly more complicated. Especially once you take into account that another refresh could happen while readers are still now in both maps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants