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

MutexGuard and others should be Send #23465

Closed
theemathas opened this issue Mar 18, 2015 · 4 comments
Closed

MutexGuard and others should be Send #23465

theemathas opened this issue Mar 18, 2015 · 4 comments

Comments

@theemathas
Copy link

MutexGuard, RwLockWriteGuard and RwLockReadGuard are currently !Send. They should be Send.

This also currently causes StdinLock and StdoutLock to be !Send.

@alexcrichton
Copy link
Member

These are actually intentionally not sendable. To quote the standard:

If a thread attempts to unlock a mutex that it has not locked or a mutex which is unlocked, undefined behavior results.

As a result these structures are not sendable as we must guarantee that the lock is only released on the same thread that acquired it.

@smessmer
Copy link

Since Rust 1.62 has a new Mutex implementation without pthread, should this be reconsidered?

@masklinn
Copy link
Contributor

Since Rust 1.62 has a new Mutex implementation without pthread, should this be reconsidered?

Unix-like OS without futexes still use pthread locks, and for windows

SRW lock must be released by the same thread that acquired it.

I also looked around and didn't find any actually stated guarantee that futexes can be released by a non-owning thread.

@haraldh
Copy link
Contributor

haraldh commented Oct 19, 2022

Since Rust 1.62 has a new Mutex implementation without pthread, should this be reconsidered?

Unix-like OS without futexes still use pthread locks, and for windows

SRW lock must be released by the same thread that acquired it.

I also looked around and didn't find any actually stated guarantee that futexes can be released by a non-owning thread.

@masklinn a futex is just an AtomicU32. As long as the thread has access to the shared memory it can "own" it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants