Selecting locking primitives for parallel programming

T HE only reason to parallelize a program is to gain performance. However, the synchronization primitives used by parallel programs can consume excessive memory bandwidth, can be subject to memory latencies, can consume excessive memory, and can result in unfair access or even starvation. These problems can outweigh the performance benefits of parallel execution. Therefore, it is necessary to understand the performance implications of synchronization primitives in addition to their correctness, liveness, and safety properties. This article presents a pattern language to assist you in selecting synchronization primitives for parallel programs. The pattern language assumes you have already chosen a locking design, perhaps by using a locking design pattern language [2].