3 ms·

I'll leave this here: https://doc.rust-lang.org/book/ch16-00-concurrency.html https://doc.rust-lang.org/book/ch16-00-concurrency.html

deleted 4y ago
[deleted]
nyanpasu64 4y ago
In terms of shared-memory threading concurrency, Send and Sync, and the distinction between &T and &Mutex<T> and &mut T, were a revelation when I first learned them. It was a principled approach to shared-memory threading, with Send/Sync banning nearly all of the confusing and buggy entangled-state codebases I've seen and continue to see in C++ (much to my frustration and exasperation), and &Mutex<T> providing a cleaner alternative design (there's an excellent article on its design at http://cliffle.com/blog/rust-mutexes/ http://cliffle.com/blog/rust-mutexes/). My favorite simple concurrent data structure is https://docs.rs/triple_buffer/latest/triple_buffer/struct.TripleBuffer.html https://docs.rs/triple_buffer/latest/triple_buffer/struct.Tr.... It beautifully demonstrates how you can achieve principled shared mutability, by defining two "handle" types (living on different threads), each carrying thread-local state (not TLS) and a pointer to shared memory, and only allowing each handle to access shared memory in a particular way. This statically prevents one thread from calling a method intended to run on another thread, or accessing fields local to another thread (since the methods and fields now live on the other handle). It also demonstrates the complexity of reasoning about lock-free algorithms (https://github.com/HadrienG2/triple-buffer/issues/14 https://github.com/HadrienG2/triple-buffer/issues/14). I suppose &/&mut is also a safeguard against event-loop and reentrancy bugs (like https://github.com/quotient-im/Quaternion/issues/702 https://github.com/quotient-im/Quaternion/issues/702). I don't think Rust solves the general problem of preventing deadlocks within and between processes (which often cross organizational boundaries between projects and distinct codebases, with no clear contract on allowed behavior and which party in a deadlock is at fault), and non-atomicity between processes on a single machine (see my PipeWire criticism at https://news.ycombinator.com/item?id=31519951 https://news.ycombinator.com/item?id=31519951). File saving is also difficult (https://danluu.com/file-consistency/ https://danluu.com/file-consistency/), though I find that fsync-then-rename works well enough if you don't need to preserve metadata or write through file (not folder) symlinks. I wonder how https://lwn.net/Articles/789600/ https://lwn.net/Articles/789600/ is doing now.
- slurpmaker 4y ago
  This triple buffer is a new one on me, super clever thanks for sharing this.
- saghm 4y ago
  & versus &mut (and the associated borrow checker rules) also stop certain types of bugs in non-concurrent code. For example, if you try to get a reference to an element in a vector, then try to clear the vector, the compiler will not allow it since you need a mutable reference to call the `clear` method, which can't be taken while a reference to an element exists (unless the reference isn't used again after the clear, in which case the compiler will recognize the lifetimes of the references don't overlap). In a GC language, the referenced object could still be kept around without needing to remain in the vector, but in a language like C/C++, you'd end up with a dangling pointer: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9da150c6d69e06ccc408724924499bc5 https://play.rust-lang.org/?version=stable&mode=debug&editio... (edited to replace poorly formatted inline code with link to playground)
- Zababa 4y ago
  Naive question, why is the triple buffer called like that?
  - slurpmaker 4y ago
    So I literally just learned about this, and it's because it is 3 buffers. I found this website to be a good high level overview: https://wiki.c2.com/?TripleBuffer https://wiki.c2.com/?TripleBuffer If that's not short enough the tl;dr is: "with Triple Buffering, there will always be a buffer to write to while a transition is in progress between the other two." The other two buffer's being producer, and consumer buffers.
- formerly_proven 4y ago
  Hah, I was thinking about how to share state from an background collector thread to the frontend thread and TripleBuffer is exactly the data structure I needed just now. Thanks! (My C++-infested instinct was to just go "naw, just slap a mutex on the data, it'll be fiiiinee", but I already knew that Rust Probably Has A Better Way For That).

deleted 4y ago

[deleted]

nyanpasu64 4y ago

In terms of shared-memory threading concurrency, Send and Sync, and the distinction between &T and &Mutex<T> and &mut T, were a revelation when I first learned them. It was a principled approach to shared-memory threading, with Send/Sync banning nearly all of the confusing and buggy entangled-state codebases I've seen and continue to see in C++ (much to my frustration and exasperation), and &Mutex<T> providing a cleaner alternative design (there's an excellent article on its design at http://cliffle.com/blog/rust-mutexes/ http://cliffle.com/blog/rust-mutexes/). My favorite simple concurrent data structure is https://docs.rs/triple_buffer/latest/triple_buffer/struct.TripleBuffer.html https://docs.rs/triple_buffer/latest/triple_buffer/struct.Tr.... It beautifully demonstrates how you can achieve principled shared mutability, by defining two "handle" types (living on different threads), each carrying thread-local state (not TLS) and a pointer to shared memory, and only allowing each handle to access shared memory in a particular way. This statically prevents one thread from calling a method intended to run on another thread, or accessing fields local to another thread (since the methods and fields now live on the other handle). It also demonstrates the complexity of reasoning about lock-free algorithms (https://github.com/HadrienG2/triple-buffer/issues/14 https://github.com/HadrienG2/triple-buffer/issues/14). I suppose &/&mut is also a safeguard against event-loop and reentrancy bugs (like https://github.com/quotient-im/Quaternion/issues/702 https://github.com/quotient-im/Quaternion/issues/702). I don't think Rust solves the general problem of preventing deadlocks within and between processes (which often cross organizational boundaries between projects and distinct codebases, with no clear contract on allowed behavior and which party in a deadlock is at fault), and non-atomicity between processes on a single machine (see my PipeWire criticism at https://news.ycombinator.com/item?id=31519951 https://news.ycombinator.com/item?id=31519951). File saving is also difficult (https://danluu.com/file-consistency/ https://danluu.com/file-consistency/), though I find that fsync-then-rename works well enough if you don't need to preserve metadata or write through file (not folder) symlinks. I wonder how https://lwn.net/Articles/789600/ https://lwn.net/Articles/789600/ is doing now.

slurpmaker 4y ago
This triple buffer is a new one on me, super clever thanks for sharing this.
saghm 4y ago
& versus &mut (and the associated borrow checker rules) also stop certain types of bugs in non-concurrent code. For example, if you try to get a reference to an element in a vector, then try to clear the vector, the compiler will not allow it since you need a mutable reference to call the `clear` method, which can't be taken while a reference to an element exists (unless the reference isn't used again after the clear, in which case the compiler will recognize the lifetimes of the references don't overlap). In a GC language, the referenced object could still be kept around without needing to remain in the vector, but in a language like C/C++, you'd end up with a dangling pointer: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=9da150c6d69e06ccc408724924499bc5 https://play.rust-lang.org/?version=stable&mode=debug&editio... (edited to replace poorly formatted inline code with link to playground)
Zababa 4y ago
Naive question, why is the triple buffer called like that?
- slurpmaker 4y ago
  So I literally just learned about this, and it's because it is 3 buffers. I found this website to be a good high level overview: https://wiki.c2.com/?TripleBuffer https://wiki.c2.com/?TripleBuffer If that's not short enough the tl;dr is: "with Triple Buffering, there will always be a buffer to write to while a transition is in progress between the other two." The other two buffer's being producer, and consumer buffers.
formerly_proven 4y ago
Hah, I was thinking about how to share state from an background collector thread to the frontend thread and TripleBuffer is exactly the data structure I needed just now. Thanks! (My C++-infested instinct was to just go "naw, just slap a mutex on the data, it'll be fiiiinee", but I already knew that Rust Probably Has A Better Way For That).