The x-Wait-Freedom Progress Condition

Abstract

The liveness of concurrent objects despite asynchrony and failures is a fundamental problem. To that end several progress conditions have been proposed. Wait-freedom is the strongest of these conditions: it states that any object operation must terminate if the invoking process does not crash. Obstruction-freedom is a weaker progress condition as it requires progress only when a process executes in isolation for a long enough period.This paper explores progress conditions in n-process asynchronous read/write systems enriched with base objects with consensus number x, 1 < x ≤ n (i.e., objects that wait-free solve consensus in a set of x processes). It is easy to solve consensus in such a system if progress is required only when one of the x processes allowed to access the underlying consensus object invokes this object and does not crash. This paper proposes and investigates a stronger progress condition that we call x-wait-freedom (n-wait-freedom is wait-freedom). While it does not need more assumptions than the previous one in order to ensure progress, that condition identifies additional scenarios in which progress is required despite the fact that none of the x processes allowed to access the underlying consensus object participates. The paper then presents and proves correct a consensus algorithm that satisfies this progress condition.

A liveness condition for concurrent objects: x‐wait‐freedom

“…This paper, an extended version of [1], is made up of five sections. The underlying system model is presented in Section 2.…”

On the Implementation of Concurrent Objects

“…The denition and investigation of new progress conditions have received a new impetus and are becoming a very active research area. The interested reader can consult the very last results in [25,26,46,47,48].…”

“…Asymmetric progress conditions have recently been dened [25,26]. The denition and investigation of new progress conditions have received a new impetus and are becoming a very active research area.…”

“…% (code for p i ) % (14) repeat forever (15) head ← (Q ↓).head; (16) tail ← (Q ↓).tail; (17) next ← ( head.ptr ↓).next; (18) if ( head = (Q ↓).head) then (19) if ( head.ptr = tail.ptr) (20) then if ( next.ptr = ⊥) then return(empty) end if; (21) ((Q ↓).tail).C&S( tail, next.ptr, tail.tag + 1 ) (22) else result ← ( next.ptr ↓).value; (23) if ((Q ↓).head).C&S( head, next.ptr, head.tag + 1 ) (24) then free( head.ptr); return(result) (25) end if (26) end if (27) end if (28) end repeat. [34] • Process p i rst makes local copies (kept in tail and next) of (Q ↓).tail and ( tail.ptr ↓).next, respectively.…”

“…% (code for p i ) % (12) pred ← HEAD; curr ← (HEAD ↓).next; (13) while ((curr ↓).val < v) do pred ← curr; curr ← (curr ↓).next end while; (14) lock`(pred ↓).lock´; valid ← false; (15) if validate(pred, curr) (16) then valid ← true; to_add ← (curr ↓).val = v); (17) if (to_add) then NEW _CELL ← new_cell(); NEW _CELL.out ← false; (20) end if (21) end if; (22) (25) while ((curr ↓).val < v) do curr ← (curr ↓).next end while; (26) …”