-
Notifications
You must be signed in to change notification settings - Fork 9
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
Fix race condition in time barriers #49
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't find any surface level flaws. I guess u just moved the functionality from the conditional variable that does the locking to the scheduler.
This pulls in lf-lang/reactor-cpp#49 to fix #1746
This pulls in lf-lang/reactor-cpp#49 to fix #1746
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Iooks good
This pulls in lf-lang/reactor-cpp#49 to fix #1746
This pulls in lf-lang/reactor-cpp#49 to fix #1746
This pulls in lf-lang/reactor-cpp#49 to fix #1746
There was a race condition in the main synchronization primitive that we use to coordinate enclaves. Our code used two separate locks, one for protecting the variable holding the last released tag and another one for receiving updates from the scheduler. However, we can only use one of the locks when calling
wait
on our condition variable. This creates a race between updating the wait condition (i.e. releasing a tag) and actually starting the wait under the second lock (Here is an explanation, see "An atomic predicate") This PR refactors the time barriers, such that the global scheduler lock is also used to protect our localreleased_tag_
variable.This adresses lf-lang/lingua-franca#1746