Notes on On the Inherent Weakness of Conditional Synchronization Primitives

As with all my handwritten notes, this has the usual disclaimer: these posts are just so I can use nice indexed search to find my notes, which are sufficient for me to recall talks and papers but probably not much use to anyone else. Conference paper here. Journal Version here

Some well-known primitive operations, such as compare-and-swap, can be used, together with read and write, to implement any object in a wait-free manner. However, this paper shows that, for a large class of objects, including counters, queues, stacks, and single-writer snapshots, wait-free implementations using only these primitive operations and a large class of other primitive operations cannot be space efficient: the number of base objects required is at least linear in the number of processes that share the implemented object. The same lower bounds are obtained for implementations of starvation-free mutual exclusion using only primitive operations from this class. For wait-free implementations of a closely related class of one-time objects, lower bounds on the tradeoff between time and space are presented

The “wait-free hierarchy” classifies multiprocessor synchronization primitives according to their power to solve consensus. The classification is based on assigning a number n to each synchronization primitive, where n is the maximal number of processes for which deterministic wait-free consensus can be solved using instances of the primitive and read write registers. Conditional synchronization primitives, such as Compare-and-Swap and Load-Linked/Store-Conditional, can implement deterministic wait-free consensus for any number of processes (they have consensus number ∞), and are thus considered to be among the strongest synchronization primitives; Compare-and-Swap and Load-Linked/Store-Conditional have consequently became the synchronization primitives of choice, and have been implemented in hardware in many multiprocessor architectures.This paper shows that, though they are strong in the context of consensus, conditional synchronization primitives are not efficient in terms of memory space for implementing many key objects. Our results hold for starvation-free implementations of mutual exclusion, and for wait-free implementations of a large class of concurrent objects, that we call Visible(n). Roughly, Visible(n) is a class that includes all objects that support some operation that must perform a “visible” write before it terminates. Visible(n) includes many useful objects; some examples are: counters, stacks, queues, swap, fetch-and-add, and single-writer snapshot objects. We show that at least n conditional registers are required by any such implementation, even if registers are of unbounded size. We also obtain tradeoffs between time and space for n-process wait-free implementations of any one-time object in Visible(n) . All these results hold for both deterministic and randomized implementations.Starvation-free mutual exclusion and wait-free implementations of some objects in Visible(n) (e.g. counters, swap and fetch-and-add) can be implemented by O(1) non-conditional primitives. Thus we believe that basing multiprocessor strong synchronization solely on conditional synchronization primitives might not be the best design choice.

Notes on On the Inherent Weakness of Conditional Synchronization Primitives

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s