4 ms·

Yes, but threads (the popular APIs - eg. POSIX threads, Win32 Threads) imply the availability of of shared mutable state, concurrency, and custom written locks.

Yes, but threads (the popular APIs - eg. POSIX threads, Win32 Threads) imply the availability of of shared mutable state, concurrency, and custom written locks. And when something is available, it will be used. Heck, you could even pass a pointer to an address in some other thread's stack with ease. The amount of experience you needed to program that, while dealing with structuring the rest of your program could be large, especially if you were adding threads to an existing program. Functional programming is cumbersome to pull off in the systems programming languages available at the time (C).

outworlder 8y ago
Indeed, threads are almost synonym with shared mutable state. If you don't want shared mutable state, then you can use a process.
rurban 8y ago
Threads are good, shared state is good if hidden behind a proper protocol, just locks are evil. Windows and POSIX are to blame. Nowadays nobody should use locks anyway, as there are much better, faster and safer variants for concurrency with native threads, based on actor capabilities and ownership, and avoid blocking IO like hell. No, not Rust. Rust did it wrong. Those who do it right are so far Pony, Midori/Singularity, and parrot with native kernel threads. With simple green threads there are some more, but they are only usable for fast IO, not fast CPU tasks.