[CONCURRENT] processing, in sharp contrast to a [PARALLEL] processing, has no specific requirements on when to start, where & in what particular order to execute and when or how to finish a set of tasks, that got a chance to be executed in a free flowing, uncoordinated fashion on a subset of available resources.
In a "just"-[CONCURRENT]
process orchestration, the code-units (be it tasks, threads, programmes... ) may but, need not, appear to get executed in some non-[SERIAL]
, overlapped in time, fashion or simultaneously (just by coincidence), all that by using more than one CPU or processor core and other shared resources to execute a program or multiple computational units.
A "just"-[CONCURRENT]
process orchestration does not warrant any mutual coordination, the less a synchronicity a True-[PARALLEL]
warrants by definition.
A "just"-[CONCURRENT]
process orchestration enables more things to happen con-currently, the process-scheduler and other constraints participate in evaluating, who gets "elected" for such a con-current processing and who not.