-
Notifications
You must be signed in to change notification settings - Fork 32
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
During racy initialization, a race can happen where a notification is dropped #138
Comments
It seems like this can also happen with the |
notgull
added a commit
that referenced
this issue
May 27, 2024
The notify() function contains two optimizations: - If the `inner` field is not yet initialized (i.e. no listeners have been created yet), it returns `0` from the function early. - If the atomic `notified` field indicates that the current notification would do nothing, it returns `0` early as well. `loom` testing has exposed race conditions in these optimizations that can cause notifications to be missed, leading to deadlocks. This commit removes these optimizations in the hope of preventing these deadlocks. Ideally we can restore them in the future. Closes #138 cc #130 and #133 Signed-off-by: John Nunley <[email protected]>
notgull
added a commit
that referenced
this issue
May 28, 2024
The notify() function contains two optimizations: - If the `inner` field is not yet initialized (i.e. no listeners have been created yet), it returns `0` from the function early. - If the atomic `notified` field indicates that the current notification would do nothing, it returns `0` early as well. `loom` testing has exposed race conditions in these optimizations that can cause notifications to be missed, leading to deadlocks. This commit removes these optimizations in the hope of preventing these deadlocks. Ideally we can restore them in the future. Closes #138 cc #130 and #133 Signed-off-by: John Nunley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following logic exists in
notify
:event-listener/src/lib.rs
Line 440 in fdbe437
The intent is to make it so
notify
ing anEvent
that has never has anEventListener
is a single atomic operation and nothing else. However, a race condition can happen here where a notification is dropped even when there is a listener available.listen()
. As part oflisten()
theinner()
function is called, which allocates theArc<Inner>
andcompare_exchanges
it into theinner
pointer.load
of theinner
pointer and the finalcompare_exchange
, Thread 0 is pre-empted and Thread 1 starts.notify
, which then callstry_inner
, whichload
s theinner
pointer. Since it hasn't been updated yet this returns0
, which thenotify
function interprets as the event not listening yet.notify
by notifying no listeners.If Thread 0 pre-empted Thread 1 while Thread 1 was updating some atomic state, this can lead to a deadlock.
The text was updated successfully, but these errors were encountered: