3 ms·
Correct, that is true for any language where you deal with raw threads, managed or unmanaged. That tells us that we should avoid using raw threads and instead u
by fetbaffe 6y ago
Correct, that is true for any language where you deal with raw threads, managed or unmanaged. That tells us that we should avoid using raw threads and instead use some other API to achieve parallelism.
- nicoburns 6y agoIt's not true in Rust. In Rust, objects cannot be concurrently accessed from multiple threads unless they are explicitly marked as thread-safe (with the Sync trait), or wrapped in a a Mutex, which ensures that the safety variants are upheld.
- fetbaffe 6y agoRust does not compile if you don't use the techniques you described?
- ansible 6y ago> Rust does not compile if you don't use the techniques you described? Yes, exactly. https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time-Memory-Safety.html https://kkimdev.github.io/posts/2019/04/22/Rust-Compile-Time... Of course, you can bypass this by using 'unsafe' code, where you are explicitly telling the compiler that you have manually verified Rust's safety guarantees. This is why a significant portion of Rust's community gets agitated with (possibly unnecessary) use of 'unsafe' in popular libraries.
- fetbaffe 6y agoThen I stand corrected and applaud the creators of Rust for haven taken these measures for writing thread safe code, because it is supereasy to get threading wrong, even for the most experienced developer.
- thePunisher 6y agoBoth Java and C# are designed for memory-safety but not thread-safety; Rust is. Considering many of the software problems we face have some connection to thread-safety, Rust is the way to go.
- pjmlp 6y agoI would consider that the way to go is multi-processes instead, and secure every critical module on their own OS sandbox. Threading seemed a good idea that went wrong.
- littlestymaar 6y agoInterestingly enough, this was the raison d'être of the Rust project at the beginning, while zero-cost abstraction and memory-safety without GC (and the borrow-checker) weren't part if the initial goal. When Rust was first released as a research project it had green threads and a GC (interestingly close to Go actually), but it was already designed with data-race freedom in mind.
- pjmlp 6y agoYes for multi-threaded code, although not quite for multi-processes code, which is what one should be writing when the goal is security. Then you are back into the same synchronization issues as in every other language.
- ReactiveJelly 6y agoAnd in the last quadrant, you can use non-raw threads like the Task or Parallel APIs and still have threading issues in C#. I'm trying to learn Android and some libraries give zero indication of what thread your callbacks will be called on. Maybe there's a convention somewhere that says "On Android, you can't assume anything about callbacks, so always assume you're on some anonymous worker thread and lock everything or dispatch to a thread you own" But I have not come across it yet.
- pjmlp 6y agoYes that is the convention. You cannot assume anything about process or thread lifetimes on Android, as the simple act of rotating the screen will restart your application, and it can be killed at any moment and restarted later, due to memory pressure, or because the use has switched applications. So whatever was the state of your application can be completely different when the callback is supposed to be invoked later on.