Using packaged_task for Concurrent Computations

Concurrent programming runs multiple tasks at the same time. That goal is useful, but it brings a practical problem: coordinating the tasks can demand a lot of the programmer's attention. In many concurrent programs, a large share of the effort goes into managing how the parts communicate, rather than into the work each part is meant to do.

Imagine two pieces of work that could happen at the same time, such as computing one result while another piece of computation proceeds independently. Before writing any code, a natural question arises: what does the programmer have to think about so that the two pieces cooperate correctly? Keep that question in mind as you read. This article looks at one way to reduce that burden, using packaged_task, and the goal is to notice where the programmer's attention ends up when packaged_task is used.

The passage this article draws on describes a case with exactly two tasks. Each task is placed on its own thread. Because the tasks sit on separate threads, they can be run potentially in parallel. In other words, the runtime may execute them at the same moment rather than one after the other.

The word potentially carries real weight here. Separate threads make parallel execution possible, but the passage does not promise that the two tasks will always overlap in time. Whether they actually run simultaneously depends on how the runtime schedules them, so the diagram shows a possibility, not a fixed schedule.

The central idea of packaged_task is that it lets the programmer concentrate on the tasks to be done rather than on the mechanisms used to manage their communication. The programmer thinks in terms of what each piece of work computes, and the coordination machinery is handled in a way that does not dominate the code.

The passage makes a specific point worth noticing: the code it presents never explicitly mentions locks. Even though the two tasks run on separate threads and may run in parallel, the code is written in terms of the tasks to be done. The coordination details do not appear as named steps the programmer has to write out. The left column in the comparison names the mechanisms a programmer would otherwise manage by hand; the right column names the things the code is about.

The following walkthrough follows one task from the point where the programmer hands it over to the point where its thread is doing the work. It is an illustrative trace built from the arrangement the passage describes; the passage itself does not detail every internal handoff.