4 ms·

Again, note the difference between parallel execution and concurrent execution. The software specifically relies on these cooperative threads not being parallel

Again, note the difference between parallel execution and concurrent execution. The software specifically relies on these cooperative threads not being parallel, which is not an inherent property of being concurrent, most certainly by definition. Reading the first part of the article is a good start on understanding the distinction. Maybe this sort of lack of a basic understanding of the concepts is why concurrent programming is hard.

kazinator 12y ago
There is no substantial difference between "parallel" and "concurrent". Bot mean "running side by side" except that by "parallel processing" we usually exclude simulated concurrency. However, simulated concurrency requires asynchronous behavior: an external event, such as a timer interrupt, or the arrival of input, can come in at any time and change the control among the tasks (preemption). This looks a lot like true parallelism and must be programmed with the same care as real parallelism, which is why we dare call it concurrency. Tasking without preemption is not concurrency. The tasks know that they cannot be preempted and rely on that assumption for their correctness. This approach falls into the same domain as the use of coroutines, or dispatch queues of lexical closures, first class continuations, generators and such: none of which represent concurrency. I do not believe I require any correction in terminology or concepts; I've been programming for 33 years, and I'm the person who invented and first implemented glibc's PTHREAD_MUTEX_ADAPTIVE_NP mutex back in 2000.