The last example is also a demonstration of the current trend in multithreaded programming. Instead of working directly with threads, we try to put as much of the ugly multithreading plumbing into ready-to-use components. The first level of such abstraction is replacing threads with tasks.

A thread is just an operating system concept; one that allows executing multiple parts of a process simultaneously. When we program with threads, we have to handle all the cumbersome minutiae related to managing operating system threads.

A task, on the other hand, is the part of code that we want to execute in parallel. When we are working with tasks, we don't care how threads are created and destroyed. We just tell the system that we want to run the task and it does the rest. 

The task is a useful step forward, but, for the majority of users tasks are still too low-level. That is why parallel programming libraries that support specialized building blocks (which I like to call...