3 ms·

I actually would disagree with the statement that "for concurrency to be useful, there must be parallelism." In my experience with handling asynchronous events

by ahelwer 14y ago

I actually would disagree with the statement that "for concurrency to be useful, there must be parallelism." In my experience with handling asynchronous events (such as input from the user, system, or network) it's much easier to handle the input in separate threads instead of polling some buffer in your top-level logic loop. That way the time slicing problem is offloaded to the OS (or whatever thread library you're using) instead of you having to worry about getting stuck in another part of your top-level loop for too long.

jules 14y ago
The reason you don't want to get stuck is because there is parallelism: between the other computers on the network and your computer, or between the between the person using the computer and your program. (this isn't really different than a disk or a network doing things in parallel with your program, only in this instance the other thing runs on flesh instead of on silicon). If the disk couldn't do things in parallel with your CPU there would be no point in avoiding to get stuck for too long in your main loop, since either one would have to wait for the other anyway.