[0]: https://github.com/frostyplanet/crossfire-rs/wiki#kanal [1]: https://news.ycombinator.com/item?id=45774086
Even folks who write modern go try to avoid overusing channels. It's quite common to see go codebases with few or no channels.
Of course it matters what synchronization primitives you choose, for the reasons you gave.
Thats not true. There are stackgul coroutine libraries in Rust too. I believe there's one called "may". They are admittedly not that widely used, but they are available.
here "parallel" is used in the most broad sense where you have (probably unrelated) tasks that are mostly independent for each other and run to completion. In that case "async" is an anti-pattern. So if you work more process-based that switch-based go!
Two acquires back to back are unnecessary here. In general, fetch_sub and fetch_add should give enough guarantees for this file in Relaxed. https://github.com/frostyplanet/crossfire-rs/blob/master/src...
Congest is never written to with release, so the Acquire is never used to form a release chain: https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...
The queue appears to close the channel twice (once per rx/tx), which is discordant with the apparent care taken with the fencing. https://github.com/frostyplanet/crossfire-rs/blob/dd4a646ca9...
The author also suggests an incorrect optimization to Tokio here which suggests a lack of understanding of what the specific guarantees given are: https://github.com/tokio-rs/tokio/pull/7622
The tests do not appear to simulate the queue in Loom, which would be a very, very good idea.
This stuff is hard. I almost certainly made a mistake in what I've written above (edit: I did!). In practice, the queue is probably fine to use, but I wouldn't be shocked if there's a heisenbug lurking in this codebase that manifests something like: it all works fine now, but in the next LLVM version an optimization pass is added which breaks it on ARM in release mode, and after that the queue yields duplicate values in a busy loop every few million reads which is only triggered on Graviton processors.
Or something. Like I said, this stuff is hard. I wrote a very detailed simulator for the Rust/C++ memory model, have implemented dozens of lockless algorithms, and I still make a mistake every time I go to write code. You need to simulate it with something like Loom to have any hope of a robust implementation.
For anyone interested in learning about Rust's memory model, I can't recommend enough Rust Atomics and Locks:
Loom is apparently this: https://github.com/tokio-rs/loom I've used tokio a bit in the past, but wasn't aware of that tool at all, looks really useful and probably I'm not alone in never hearing about it before. Any tips&tricks or gotchas with it one should know beforehand?
AceJohnny2•3mo ago
SPSC = Single Producer Single Consumer
MPMC = Multiple Producer Multiple Consumer
(I'll let you deduce the other abbreviations)
endorphine•3mo ago
M = Multi
---
C = Consumer
P = Producer
wartywhoa23•3mo ago
surajrmal•3mo ago
wartywhoa23•3mo ago
dietr1ch•2mo ago
We read left to right, so <producer>:<consumer> is the natural order.