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

Implement MessageQueue without locks #6837

Closed
brson opened this issue May 30, 2013 · 7 comments
Closed

Implement MessageQueue without locks #6837

brson opened this issue May 30, 2013 · 7 comments
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows

Comments

@brson
Copy link
Contributor

brson commented May 30, 2013

MessageQueue is the way schedulers communicate with each other. It is a multiple-producer, single-consumer unbounded queue.

@brson
Copy link
Contributor Author

brson commented Jun 5, 2013

@Thiez is working on this

@msullivan
Copy link
Contributor

How's this going?

@Thiez
Copy link
Contributor

Thiez commented Jul 28, 2013

I've had https://github.com/Thiez/rust/blob/ll-message-queue/src/libstd/rt/message_queue.rs lying around for a while now. It is a Michael-Scott lockless queue as described here http://www.cs.rochester.edu/~scott/papers/1996_PODC_queues.pdf . However, since Rust does not (at this time) have an intrinsic for double-word compare-and-swap, my version is considerably more vulnerable to the ABA-problem and thus I am hesitant to declare this queue complete.
Adding a DWCAS intrinsic is not a good option as it is not supported on all the architectures we target. I think the best option would be to have a ABA-safe atomic pointer type defined in the library (it would help with the implementation of other datastructures as well). I suspect such a thing could be implemented for each target architecture with some #[cfg(target_arch = <sometarget>)] annotations; using LLVM would be tricky as it has no IR instruction that captures the semantics of of LL/SC (on architectures such as ARM).
I have no MIPS or multicore ARM devices lying around so I would not be able to test such a pointer.

To summarize, the basic algorithm is implemented and appears to work (without leaking memory, or so valgrind tells me) but it's going to fail randomly (but rarely) when at least two threads are writing and one thread is reading.
Currently there's manual malloc/free in the code but now that ~ has lost the headers the malloc could be replaced by a normal ~ followed by a transmute (and transmute back to ~ to delete).

Suggestions are welcome.

@plokhotnyuk
Copy link

I used lock-free MPSC queue that was described by Dmitriy Vyukov (http://www.1024cores.net/home/lock-free-algorithms/queues/non-intrusive-mpsc-node-based-queue) to implement one of fastest and lightweight actor for JVM: https://github.com/plokhotnyuk/actors/blob/master/src/test/scala/com/github/plokhotnyuk/actors/Actor2.scala

@brson
Copy link
Contributor Author

brson commented Aug 17, 2013

The biggest place where we need to reduce lock contention is the global sleeper list #6838. Its lock is just getting hammered constantly. There are lots of ways we might fix this but an obvious one to replace it with a lock-free queue.

@Thiez
Copy link
Contributor

Thiez commented Sep 2, 2013

@plokhotnyuk thanks for that link, implementing it in rust was incredibly easy https://github.com/Thiez/rust/blob/better-message-queue/src/libstd/rt/message_queue.rs
@brson did you have a good benchmark for message-passing lying around?

@alexcrichton
Copy link
Member

Closed by #9710

flip1995 pushed a commit to flip1995/rust that referenced this issue Mar 25, 2021
`explicit_deref_methods` improvements

Breaking up rust-lang#6837

changelog: `explicit_deref_methods` will lint chained `deref` calls and ufcs style calls
flip1995 pushed a commit to flip1995/rust that referenced this issue Jun 4, 2022
new lint: `borrow_deref_ref`

changelog: ``[`borrow_deref_ref`]``

Related pr: rust-lang#6837 rust-lang#7577
`@Jarcho` Could you please give a review?

`cargo lintcheck` gives no false negative (but tested crates are out-of-date).

TODO:
1. Not sure the name. `deref_on_immutable_ref` or some others?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-runtime Area: std's runtime and "pre-main" init for handling backtraces, unwinds, stack overflows
Projects
None yet
Development

No branches or pull requests

5 participants