3 ms·
> And the fix is to deprecate shared memory multithreading altogether. Not gonna happen without a radically different CPU, OS, and application software paradig
by adwn 8y ago
> And the fix is to deprecate shared memory multithreading altogether.
Not gonna happen without a radically different CPU, OS, and application software paradigm. In other words: extremely unlikely in the next 2-3 decades (at least).
> It's too hard to use
Agree for most languages. Have you tried Rust? It makes shared memory multi-threading not just much simpler, but also safe.
> too slow
Very wrong for multi-core CPUs, where message-passing is emulated using shared memory.
> too broken
What does that even mean? With the right language-enforced mechanism, it is very much non-broken and functional.
> and has no future either way.
Very wrong, see first paragraph.
- lmm 8y ago> Have you tried Rust? It makes shared memory multi-threading not just much simpler, but also safe. It makes it safe by not letting you share; data is owned explicitly and passed explicitly.
- adwn 8y ago> It makes it safe by not letting you share That is simply wrong. Rust makes it easy and safe to share immutable data – it's the ability to mutate that can't be shared. > data is owned explicitly and passed explicitly Yes, data is owned explicitly, but the permission to read or write the data is somewhat independent of ownership – the owner of an object can grant permission to access the object, and it can pass this permission to other threads without relinquishing ownership.
- steveklabnik 8y ago> it's the ability to mutate that can't be shared. So, I do think you're more right than your parent, but I also think this formulation misses important things. Rust only lets you share when you cannot cause a data race. A type like Mutex lets you share something that's mutable, because the mutex is guarding the sharing. Functions like split_at_mut let you mutably share disjoint parts of a slice.