4 ms·
Um, this is all very standard stuff - if you want thread safety you should use queues or locks. Just because a language doesn't have first-class support for mul
by akvadrako 8y ago
Um, this is all very standard stuff - if you want thread safety you should use queues or locks. Just because a language doesn't have first-class support for multithreading doesn't mean you shouldn't use it.
You should use explicit synchronisation even when using Python, which has that terrible global lock. Relying on atomic operations is too error prone and not explicit enough.
- raphlinus 8y agoC and C++ are sharp tools. They have extensive undefined behavior, but also a formal memory model, so it means something to say, "this code is correct." They also have a culture of people who understand how to deal with undefined behavior, and tools (sanitizers) that make it more feasible. Rust is safe, unless you go out of your way to be unsafe. It's not just "use a lock," it's "if you try to access shared mutable data without a lock, your program won't compile." Java has data races but not undefined behavior. It also has a formal memory model. Swift gives you none of that. Treating threads as a library rather than something with language support is something that might have seemed like a good idea 20 years ago, but now I think we know better.
- tinus_hn 8y agoThe C model is ‘there is only one core, race conditions don’t exist. Multithreading is undefined.’ How is that better?
- lifthrasiir 8y agoThat has been changed in C11 to match with C++11, in case you are not aware.