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

[workstealer] at most once execution semantics #26

Open
aavarghese opened this issue Jul 23, 2024 · 0 comments
Open

[workstealer] at most once execution semantics #26

aavarghese opened this issue Jul 23, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@aavarghese
Copy link
Member

Right now, we have at least once task execution semantics. I.e. it is possible that the same task may be processed twice. This can happen due to the lockless implementation of the workstealer. There are race windows between worker deciding to work on a task and work stealer deciding to steal that task.

We can probably add at most once semantics without massive reengineering.

Prototype Idea

  • worker observes a file in inbox. Today it will start working on it immediately. Proposal: instead, touch a {task}.trylock file. Wait until a {task}.trylock.ack file exists. If that object says "yes", then proceed; if it says "no", then skip
  • workstealer observes {task}.trylock. if it hasn't yet stolen the work from that worker, it will ack with yes; otherwise ack with no
  • workstealer only steals non-trylocked tasks
@aavarghese aavarghese added the enhancement New feature or request label Jul 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant