4 ms·
Great question! In C++, yes. When I did a clasp in C++, I had a mutex on each side, where the "primary" one locked its mutex then locked the other, and the "sec
by verdagon 6y ago
Great question! In C++, yes. When I did a clasp in C++, I had a mutex on each side, where the "primary" one locked its mutex then locked the other, and the "secondary" one would instead lock its mutex and try-lock the other. Then, it would sever the pointers in both.
Vale, like Rust, isolates its threads' memory regions from each other, and also allows borrowing from mutexes. (Vale will use region-based borrow checking rather than Rust's object-based kind)
You're quite right about the rvalue-reference qualified member functions! There's one hiccup though; it can't be used with unique_ptr. I think theres an obscure note in the article that mentions that C++ could use Rust's "Arbitrary Self Types" to really close this hole. At that point, C++ might be able to have this kind of improved RAII!
- steveklabnik 6y agoRust does not provide any specific isolation between threads' memory. You can Send an &mut T to another thread, and it will be able to mutate your memory.
- nybble41 6y ago> You can Send an &mut T to another thread, and it will be able to mutate your memory. Mutable references are exclusive. If you Send an &mut T to another thread then it isn't really your memory any more—you can't read from it or write to it unless the other thread somehow Sends the reference back.
- steveklabnik 6y agoIf it gets sent back or if it ends execution, which releases the &mut T, and the borrow. It isn't your memory temporarily. If it was forever, you'd be passing ownership, not a reference.
- atq2119 6y agoIn other words, Rust provides the isolation that was originally mentioned. That there are mechanisms by which the isolation boundary can shift does not change that.
- steveklabnik 6y agoI guess we’re arguing about definitions :) nothing about this is specific to threads, and to me, thread isolation means that threads are forbidden from writing to each other’s memory entirely. Maybe my understanding of the definition is idiosyncratic!
- nybble41 6y agoI think the point that verdagon was making regarding "isolation" was that the Rust ownership and borrowing rules prevent any concurrency issues from arising. At the OS level threads, by definition, share all their memory—that's the primary factor that distinguishes them from processes—so it doesn't really make sense to talk about memory belonging to a particular thread at that level. Most other languages do not have that level of isolation and would not actively prevent multiple threads from accessing the same mutable memory location. In one sense it's true that in Rust terms the actual ownership of the memory remains with the original thread, and the receiving thread is only borrowing it, but the reality is a bit stricter than that would imply since the borrowing thread has exclusive access for the duration of the borrow and can't be forced to give it up. To me, "which stack was the object allocated from" is less important than "which thread actually has control right now".
- steveklabnik 6y agoYeah, and it's possible I'm over-indexing on something like an Erlang-style green thread model, where shared state is (almost) forbidden, and thinking that's what was being referred to.