4 ms·

I think this is the point that's often overlooked. Everything in safe rust is supposed to be both memory safe and thread safe. The textbook implementation of li

I think this is the point that's often overlooked. Everything in safe rust is supposed to be both memory safe and thread safe. The textbook implementation of linked lists and trees are not thread safe, and easily not memory safe.

bluejekyll 9y ago
I’ll be the pedantic one. It doesn’t guarantee thread safety, it guarantees that its data race free. In practice this often reduces to the same thing, but you can still create deadlocks, etc.
- madez 9y ago
  Yes, you are correct. Rusts safety does not rule out deadlocks. Guaranteeing data-race-freeness is however already enough to reject intuitive doubly-linked lists. Thanks for bringing that up, which I don't think is pedantic.
zenhack 9y ago
Lots of (most?) rust libraries are "not thread safe" in the sense that those data structures aren't though. The reason this is ok is that to actually share a piece of data across threads it needs to implement Sync (which requires unsafe). Also, as a sibling comment points out, the "thread safety" guarantee is relatively narrow -- it won't guarantee a general lack of concurrency bugs any more than a gc will guarentee reasonable memory usage. I haven't thought through the details, but I suspect it's possible to adjust the semantics of rust in a way that allows multiple mutable references without sacrificing memory safety. What you would hit is that the compiler would be hindered when doing optimizations in the same way that c and c++ compilers are, because of pointer aliasing. There's a trade off there, and I think you can make the argument either way.
- steveklabnik 9y ago
  Sync is implemented automatically for most types; if you want to tell the compiler something is Sync when it thinks it isn’t, that’s when you need unsafe. Same with Send, which is more primitive than Sync.
  - zenhack 9y ago
    Ah, point. That would probably need to change to relax the one mutable reference constraint, if you wanted to.
- littlestymaar 9y ago
  > I haven't thought through the details, but I suspect it's possible to adjust the semantics of rust in a way that allows multiple mutable references without sacrificing memory safety. Please do think about the details deeply, because if you find a way to do this, you'll probably bring a revolution to Rust. I'm kind of skeptical of course, but I'd be really happy to be wrong.

bluejekyll 9y ago

I’ll be the pedantic one. It doesn’t guarantee thread safety, it guarantees that its data race free. In practice this often reduces to the same thing, but you can still create deadlocks, etc.

madez 9y ago
Yes, you are correct. Rusts safety does not rule out deadlocks. Guaranteeing data-race-freeness is however already enough to reject intuitive doubly-linked lists. Thanks for bringing that up, which I don't think is pedantic.

zenhack 9y ago

Lots of (most?) rust libraries are "not thread safe" in the sense that those data structures aren't though. The reason this is ok is that to actually share a piece of data across threads it needs to implement Sync (which requires unsafe). Also, as a sibling comment points out, the "thread safety" guarantee is relatively narrow -- it won't guarantee a general lack of concurrency bugs any more than a gc will guarentee reasonable memory usage. I haven't thought through the details, but I suspect it's possible to adjust the semantics of rust in a way that allows multiple mutable references without sacrificing memory safety. What you would hit is that the compiler would be hindered when doing optimizations in the same way that c and c++ compilers are, because of pointer aliasing. There's a trade off there, and I think you can make the argument either way.

steveklabnik 9y ago
Sync is implemented automatically for most types; if you want to tell the compiler something is Sync when it thinks it isn’t, that’s when you need unsafe. Same with Send, which is more primitive than Sync.
- zenhack 9y ago
  Ah, point. That would probably need to change to relax the one mutable reference constraint, if you wanted to.
littlestymaar 9y ago
> I haven't thought through the details, but I suspect it's possible to adjust the semantics of rust in a way that allows multiple mutable references without sacrificing memory safety. Please do think about the details deeply, because if you find a way to do this, you'll probably bring a revolution to Rust. I'm kind of skeptical of course, but I'd be really happy to be wrong.