-
Notifications
You must be signed in to change notification settings - Fork 29
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
GenericMutexGuard should be marked !Sync #53
Comments
You are right - this is wrong. The |
ammaraskar
added a commit
to ammaraskar/futures-intrusive
that referenced
this issue
Oct 31, 2020
ammaraskar
added a commit
to ammaraskar/futures-intrusive
that referenced
this issue
Nov 1, 2020
Hey @Matthias247, would you mind publishing a new version of this crate with this fix included? |
0.4 is published: https://crates.io/crates/futures-intrusive |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think the
GenericMutexGuard
object should me marked explicitly as!Sync
, it looks like it was automatically given theSync
trait because it only consists of aGenericMutex
reference which itself isSync
. However, the lock-guard object itself shouldn't be usable across threads because it assumes it has the lock acquired. (This issue was found by the Rust group at @sslab-gatech).Here's a demonstration of how this can cause
Cell
, a non-Sync but Sendable type to be used across threads to create a data race:Output:
The text was updated successfully, but these errors were encountered: