You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description:
There are some types in tokio::sync which keep a shared state behind a mutex and expose methods to modify it through a shared reference. Two instances were uncovered. One was solved and merged, while the other one is waiting to avoid merge conflict. Now we need to identify all other instances in tokio::sync where this bug occurs. I found that the key thing that is held in common among lines that produce this deadlock is that they have a statement containing the waiter keyword. Applying appropriate changes to each of the below lines might result in a guarantee of this deadlock bug never occurring again in tokio::sync.
Task: go through every type in tokio::sync and check whether they have this bug.
Lines containing waker in statement:
Lines containing waker in statement:
mpsc/chan.rs
327 (initialize)
mpsc/unbounded.rs
no statements
task/atomic_waker.rs
195 (initialize)
200 (initialize)
204 (risky assignment)
237 (initialize)
246 (old waker saved)
251 (condition)
262 (condition)
304 (condition)
320 (initialize)
barrier.rs
no statements
batch_semaphore.rs
232 (initialize)
233 (condition)
285 (initialize)
306 (condition)
452 (reformulation)
459 (old waker saved)
broadcast.rs
772 (initialize)
903 (condition)
915 (risky assignment)
1169 (condition)
notify.rs
464 (condition)
503 (initialize)
533 (condition)
603 (initialize)
771 (risky assignment)
835 (risky assignment)
868 (condition)
874 (risky assignment)
939 (condition)
oneshot.rs
412 (initialize)
419 (initialize)
427 (risky write)
The text was updated successfully, but these errors were encountered:
This is a branch from #5429.
Description:
There are some types in tokio::sync which keep a shared state behind a mutex and expose methods to modify it through a shared reference. Two instances were uncovered. One was solved and merged, while the other one is waiting to avoid merge conflict. Now we need to identify all other instances in
tokio::sync
where this bug occurs. I found that the key thing that is held in common among lines that produce this deadlock is that they have a statement containing thewaiter
keyword. Applying appropriate changes to each of the below lines might result in a guarantee of this deadlock bug never occurring again intokio::sync
.Task: go through every type in
tokio::sync
and check whether they have this bug.Lines containing
waker
in statement:Lines containing
waker
in statement:The text was updated successfully, but these errors were encountered: