3 ms·
> The programmer didn’t follow basic, well known development practices. Multithreaded programs seem harder or more complex to write because two or more concurre
by gnuvince 13y ago
> The programmer didn’t follow basic, well known development practices. Multithreaded programs seem harder or more complex to write because two or more concurrent threads working incorrectly make a much bigger mess a whole lot faster than a single thread can.
Actually, I prefer to think that the reason multi-threaded programs are harder to write is because it's harder to compose components together. If I have a regular old function and another regular old function and compose them, I get a regular old function and I know that it works how I expect it. With two multi-threaded functions, then I have no guarantees anymore. If I cannot take simple components and combine them into more complex ones, how am I suppose to write correct code? Sorry, but I'm just not good enough.
- Jtsummers 13y agoThis is where language choice and concurrency libraries become critical. Erlang's (IME) processes are nearly as composable as functions. With golang's channels allow something similar. ZMQ seems to provide a similar mechanism in a language agnostic fashion, though that seems to be about connecting multiple processes rather than threads (do people use ZMQ for interthread communication and syncronization?).