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

mutexes should be separate from condition variables #10574

Closed
thestinger opened this issue Nov 20, 2013 · 3 comments
Closed

mutexes should be separate from condition variables #10574

thestinger opened this issue Nov 20, 2013 · 3 comments
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@thestinger
Copy link
Contributor

It's very common to use a single mutex with many condition variables.

Windows Vista and later have support for native condition variables without emulation. Windows XP support ends in April 2014 so there's no need for Rust to cripple the API to support it.

A simple example: https://github.com/thestinger/rust-core/blob/master/core/concurrent.rs#L73

@sfackler
Copy link
Member

extra::Mutex can be initialized with multiple condition variables, though you can't use the Condvar without holding the associated lock first. The API's also a bit awkward.

@thestinger
Copy link
Contributor Author

To clarify, I'm talking about the native std::unstable::Mutex type. The type in extra is a slow implementation on top of the scheduler. A high quality mutex like the ones provided by glibc and Windows will do a micro-optimized spin before falling back to a fast system call to block. If there isn't a need to block, there will be no system call or context switch.

@alexcrichton
Copy link
Member

Fixed in #19274.

flip1995 pushed a commit to flip1995/rust that referenced this issue Apr 6, 2023
Update subtree sync docs for changes in rustc-dev-guide

Companion PR to rust-lang/rustc-dev-guide#1653. That still keeps a `contributing.html` with an "External Contributions" section, so hopefully it won't be too disruptive.

changelog: none
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

3 participants