Press the title of this page to see all pages with this category.

DesignPatterns concerned with concurrency issues are collected in the CategoryConcurrencyPatterns.

Aliases: Parallelism, ParallelProgramming. 

'''Concurrency vs. Parallelism:''' since people get these confused all the time. 
* '''concurrency''' is a semantic property. You know two tasks T1 and T2 are 'concurrent' if this can express itself in the program semantics. This often manifests in the form of indeterminism and RaceCondition''''''s, but there are also forms of deterministic concurrency where reasoning about program liveness requires knowing that certain program elements are concurrent.
* '''parallelism''' is an implementation property. Two tasks T1 and T2 are 'parallel' if they are computed at the same time.

In general, concurrency ''allows'' for parallelism, ''but does not strongly imply it''. That is, one may sequentially execute a concurrent program, only interleaving when synchronization between tasks is required. Further, parallelism does not imply concurrency; it is often possible for an optimizer to take programs with no ''semantic'' concurrency and break them down into parallel components via such techniques as task pipelines, wide vector SIMD operations, divide-and-conquer. 

These concepts aren't even especially related in practice. There is great interest in ParallelProgramming from the scientific and multimedia (e.g. motion picture) industries. There is great interest in concurrency from the distributed systems and systems software folk. Fortunately, it is often possible to combine the techniques in a (mostly) orthogonal manner.

----
See Also: CategoryDistributed
----

CategoryCategory