Local variables. Each process pi manages the following local variables: parti is used to locally store a copy of the snapshot object PART ; counti is a local counter; and groupi a binary variable whose value belongs to {1, 2}. − Behavior of a process pi. Algorithm 1 describes the behavior of a process pi. When it invokes propose(ini) (where ini is the value it proposes), pi first indicates it is participating (line 1). Then it invokes the snapshot object until at least n t processes are participating (lines 2-4). When this oc- curs, pi enters group 1 or group 2 according to the value of its counter counti (line 5), and launches in parallel two threads T 1 and T 2 (line 6). In the thread T 1, pi loop forever until DEC contains a proposed value. When this happens pi decides it (line 7). The execution of return() at line 7 or 12 terminates the invocation of propose(). The thread T 2 is the core of the algorithm. Process pi tries to enter the critical section controlled by either the f -mutex or the m-mutex object MUTEX [groupi] (line 9). If it succeeds and DEC has still its initial default value, pi assigns it the value ini it proposed (line 10). Finally, pi releases the critical section (line 11), and decides (line 12). Let us remind that, as far as MUTEX [1] (respectively, MUTEX [2]) is concerned, up to f (respectively, m) processes can simultaneously execute line 10.
Local variables. Each process pi manages the following local variables: parti is used to locally store a copy of the snapshot object PART ; counti is a local counter; idi and new_namei are used to store the original and new names, respectively. − Behavior of a process pi. Algorithm 2 describes the behavior of a process pi. Every process pi keeps on taking snapshots until it notices that n t processes (including itself) are participating. Then, the process invokes a rename operation of a RENAMINGf object, stores the value of its new name in new_namei, and returns this value.
Local variables. For each iteration j, party Pi maintains several variables: i • L(j) contains the set of values to which Pi is “locked,” or ⊥ if it is not locked. Pi will not commit to any other set in iteration j if it is locked. i • HardLocked(j) ∈ {0, 1} is a boolean variable indicating whether Pi is “hard locked” to the set L(j). When Xx is hard locked to a set, it will commit to the set regardless of any proposal in iteration j. i • T (j) records the sets from “valid proposals” received in iteration j. As part of the security proof, we show that the output must always be such a set. Since, apart from the proposal and preround, the protocol only requires parties to exactly compare sets, it is ok to replace the encodings of sets in these rounds with the hash of the set.
