Questions tagged [concurrent-programming]

[CONCURRENT] programming refers to a system design paradigm, where multiple actions may be scheduled to execution at any time and if more resources are available, some may happen to become executed simultaneously.

A concurrent run of a code-execution happens simultaneously _{(just by coincidence)},
using more than one CPU or processor core
and other shared resources to execute a program
or multiple _{(but mutually independent)}
computational units (tasks, threads, et al).

With this said, the option for them to interact with each other exists, but requires additional steps and measures so as to avoid their one-side lock inefficiencies, plus a risk of a mutual locking.

Usually, concurrent programming has to provide additional validation of correctness and robustness against uncoordinated processing units' failures, deadlocking et al, while it may -- just by a weak-coincidence -- benefit from a better resources usage (higher occupancy rate than with just a [SERIAL] arrangement of execution), which, with respect to the need of algorithmically assure the set former robustness goals, does not assure an end-to-end performance of the concurrent processing scales linearly with an amount of resources available (_{ref. below - non-linear expansion of resource arbitration overheads}).

Usually, concurrent programming involves control over shared resources, which is achieved by implementing "arbiters" that handle the access to those resources and distribute the resources among all processes/threads.

A professional & principal disambiguation between [PARALLEL] vs. [CONCURRENT] is needed, as true parallel code-execution requires much more than just having a few cores and a fan-out of a horde of (uncoordinated) threads, hunting for time-sharing access to a pool of system-reserved resources. Concurrent execution is simply by far not a parallel-processing

A good Rob Pike's speech on common misunderstanding on this subject