1: \documentclass[11pt]{article}
2:
3:
4: %\documentclass[twoside,leqno,twocolumn]{article}
5: %\usepackage{llncs}
6:
7:
8: % theorems and such
9: \newtheorem{theorem}{Theorem}
10: \newtheorem{lemma}{Lemma}
11: \newtheorem{corollary}{Corollary}
12: \newtheorem{fact}{Fact}
13: \newtheorem{proposition}{Proposition}
14: \newtheorem{definition}{Definition}
15: \newtheorem{observation}{Observation}
16:
17: \newenvironment{proof}{\noindent\mbox{\bf Proof }}{\hfill\mbox{
18: $\bigtriangledown$}\medskip\par}
19: \newenvironment{remark}{\medskip\noindent\mbox{\bf Remark }}{\medskip\par}
20:
21: %\newcommand{\comment}[1]{\bigskip\par\noindent{\sl Hidden Comment}\bigskip\par}
22: %\newcommand{\comment}[1]{}
23: \newcommand{\id}{\mbox{\sc id}}
24: \newcommand{\polylog}{\mbox{polylog}}
25:
26: \def\rem#1{{\marginpar{\raggedright\scriptsize #1}}}
27:
28:
29:
30: % European A4
31: %\oddsidemargin 0in
32: %\topmargin 0in
33: %\headheight 0in
34: %\headsep 0in
35: %\textheight 23.5cm
36: %\textwidth 16cm
37: %\hsize=7.5in
38: %\vsize=11.0in
39:
40: % US letter
41: \oddsidemargin -0.25in
42: \topmargin 0in
43: \headheight 0in
44: \headsep 0in
45: \textheight 9.25in
46: \textwidth 7in
47: \hsize 8.5in
48: \vsize 11.0in
49:
50: \begin{document}
51:
52: \newcommand{\newspacing}{\baselineskip=1.2\normalbaselineskip}
53: \newspacing
54:
55:
56:
57: \title{\vspace*{.1cm}\bf On the Importance of Having an Identity or, \\
58: is Consensus really Universal?}
59: \author{\small Harry Buhrman \\
60: \small CWI, Amsterdam
61: \and
62: \small Alessandro Panconesi \\
63: \small DSI, La Sapienza di Roma
64: \and
65: \small Riccardo Silvestri \\
66: \small DSI, La Sapienza di Roma
67: \and
68: \small Paul Vitanyi \\
69: \small CWI, Amsterdam
70: }
71: \date{}
72: \maketitle
73:
74: \begin{abstract}
75: We show that Naming-- the existence of distinct IDs known to all-- is
76: a hidden, but necessary, assumption of Herlihy's universality result
77: for Consensus. We then show in a very precise sense that Naming is harder than Consensus
78: and bring to the surface some important differences existing
79: between popular shared memory models.
80: \end{abstract}
81:
82:
83:
84:
85: \section{Introduction}
86: The consensus problem enjoys a well-deserved reputation in the
87: (theoretical) distributed computing community.
88: Among others, a seminal paper of Herlihy added further evidence
89: in support of the claim that consensus is indeed a key theoretical construct
90: \cite{herlihy}. Roughly speaking, Herlihy's paper
91: considers the following problem: Suppose that, besides
92: a shared memory, the hardware of our asynchronous, parallel machine
93: is equipped with objects (instantiations) of certain
94: abstract data types $T_1, T_2, \ldots, T_k$;
95: given this, is it possible to implement objects of a new abstract data
96: type $Y$ in a fault-tolerant manner?
97: The notion of fault-tolerance
98: adopted here is that of wait-freedom, i.e. $(n-1)$-resiliency \cite{herlihy}.
99: This question is the starting point of an interesting theory leading
100: to many results and further intriguing questions
101: (see \cite{herlihy,jayanti} among others). One of the
102: basic results of this theory, already contained in the original article
103: of Herlihy, can be stated, somewhat loosely, as follows:
104: If an abstract data type $X$, together with a shared memory,
105: is powerful enough to
106: implement consensus for $n$ processes in a fault-tolerant manner then, $X$,
107: together with a shared memory, is also powerful enough to implement
108: in a fault-tolerant manner for $n$ processes
109: any other data structure $Y$. This is Herlihy's celebrated
110: universality result for consensus.
111:
112: In this paper we perform an analysis of some of the basic
113: assumptions underlying Herlihy's result and discover several interesting
114: facts which, in view of the above, are somewhat counter-intuitive
115: and that could provocatively be summarized by the slogans
116: ``consensus without naming is not universal'' and
117: ``naming with randomization is universal.''
118: To state our results precisely we shall recall some definitions
119: and known results.
120: % The present discussion will be somewhat informal and we refer to
121: % Section~\ref{prelims} for more formal definitions.
122:
123: In the {\bf consensus} problem we are given a set of
124: $n$ asynchronous processes that, as far as this paper is concerned,
125: communicate via a shared-memory.
126: Every process has its own input bit and is to produce its own output bit.
127: Processes can suffer from {\bf crash failures}.
128: The problem is to devise a protocol that can withstand up to
129: $(n-1)$ crash failures, i.e. a {\bf wait-free} protocol, satisfying the following
130: conditions:
131: \begin{itemize}
132: \item
133: Every non-faulty process terminates;
134: \item
135: All output bits are the same and,
136: \item
137: The output bit is the input bit of some process.
138: \end{itemize}
139:
140: The {\bf naming} problem on the other hand, is as follows:
141: Devise a protocol for a set of $n$ asynchronous processes
142: such that, at the end, each non faulty process has selected
143: a unique identifier (key).
144: If processes have identifiers to start with then we have the
145: {\bf renaming} problem.
146:
147: In some sense, this paper is about the relative complexity of naming
148: to consensus, and viceversa.
149: We shall mostly concern ourselves with
150: {\bf probabilistic protocols}-- every process in the system,
151: modeled as an i/o automaton, has access to its own source of
152: unbiased random bits-- for systems consisting of
153: {\bf asynchronous} processes communicating via a {\bf shared memory}.
154: %Recall that a {\em Las Vegas} protocol is always correct and that only
155: %the running time is a random variable, whereas for a
156: %{\em Montecarlo} protocol correctness too is a random variable.
157: The availability of objects of abstract data type {\tt consensus}
158: and {\tt naming} is assumed. An object of type {\tt consensus} is a subroutine with input
159: parameter $b \in \{0,1\}$. When invoked
160: by a process $p$ a bit $b'$ is returned. This bit is the same to all
161: invoking processes and is equal to some of the input bits, i.e. if $b'$ is returned some $p$
162: must have invoked the object with input parameter $b'$.
163: An object of type {\tt naming} is a subroutine without input parameters that,
164: when invoked by a process $p$, returns a value $v_p \in \{1,..,n\}$, $n$ being
165: the overall number of
166: processes. For any two processes $p \neq q$ we have that $v_p \neq v_q$.
167:
168: The protocols we devise should be wait-free in spite of the {\bf adversary},
169: the ``malicious'' non-deterministic scheduling agent (algorithm) modeling
170: the environment. The adversary decides which, among
171: the currently pending operations, goes on next. Pessimistically one assumes
172: that the adversary is actually trying to force the
173: protocol to work incorrectly and that the next scheduling decision--
174: which process moves next-- can be based on the whole past history of
175: the protocol execution so far. This is the so-called {\em adaptive}
176: or {\bf strong} adversary.
177: In contrast, sometimes it is assumed that the adversary decides the
178: entire execution schedule beforehand. This is the so-called
179: {\em oblivious} or {\bf weak} adversary.
180:
181: In the literature two shared-memory models are widespread.
182: The first assumes multiple reader - multiple writer registers.
183: In this model each location of the shared memory can be written
184: and read by any process.
185: The other model assumes multiple reader - single writer
186: registers. Here, every register is owned by some unique process, which is
187: the only process that can write on that register, while every
188: process is allowed to read the contents of any register.
189: In both models reads and writes are atomic operations; in case of
190: concurrent access to the same register it is assumed that the
191: adversary ``complies with'' some non-deterministic, but fair, policy.
192: In this paper we shall refer to the first as the {\bf symmetric}
193: memory model and to the second as the {\bf asymmetric} memory model.
194:
195: We are now ready to state the results of this paper.
196: Let us start by restating Herlihy's universality result
197: in our terminology. \newline
198:
199: \noindent
200: {\bf Theorem.} [Herlihy]
201: {\em
202: Suppose that $n$ asynchronous processes interact via a shared memory
203: and that,
204: \begin{itemize}
205: \item[\em (i)]
206: Memory is symmetric;
207: \item[\em (ii)]
208: Each process has its own unique identifier;
209: \item[\em (iii)]
210: Objects of type {\tt consensus} are available to the processes.
211: \end{itemize}
212: Then, any abstract data type $T$ can be implemented in a wait-free
213: manner for the $n$ processes. } \newline
214:
215: The first question we consider in this paper is: What happens
216: if the second hypothesis is removed? Can distinct identifiers
217: be generated from scratch in this memory model?
218: The answer is negative, even assuming the availability of
219: consensus objects.
220: \begin{proposition}\label{namImp}
221: {\em [Naming is impossible]}
222: Suppose that $n$ asynchronous processes \underline{without identifiers}
223: interact via a shared memory and that,
224: \begin{itemize}
225: \item[\em (i)]
226: Memory is symmetric;
227: \item[\em (ii)]
228: Each process has access to its own source of unbiased random-bits;
229: \item[\em (iii)]
230: Objects of type {\tt consensus} are available to the processes;
231: \item[\em (iv)]
232: The adversary is weak.
233: \end{itemize}
234: Yet, wait-free Las Vegas naming is impossible.
235: \end{proposition}
236: This result is simple to prove, but it is interesting in several respects.
237: First, it says that in a model more powerful than
238: Herlihy's, no protocol can produce distinct identifiers with certainty.
239: Therefore consensus by itself is {\bf not} universal,
240: for wait-free naming objects cannot be implemented in a wait-free manner
241: with consensus alone.
242:
243: Recall that a Las Vegas protocol is always correct and that only
244: the running time is a random variable, while for a
245: Montecarlo protocol correctness too is a random variable.
246: Note that Montecarlo naming is trivial-- each process generates
247: $O(\log n)$ many random bits and with probability $1-o(1)$ no two
248: of them will be identical. Therefore, at least at the outset, only the question
249: of the existence of Las Vegas protocols is of interest.
250:
251: Proposition~\ref{namImp} shows that the power of randomization to
252: ``break the symmetry''is limited. If we start from a completely
253: symmetric situation, it is
254: impossible to generate identifiers that are surely distinct.
255:
256: In stark contrast with the previous result, as we prove in this paper, the following
257: holds.
258: \begin{theorem}\label{easyCon}
259: {\em [Consensus is easy]}
260: Suppose that $n$ asynchronous processes \underline{without identifiers}
261: interact via a shared memory and that,
262: \begin{itemize}
263: \item[\em (i)]
264: Memory is symmetric;
265: \item[\em (ii)]
266: Each process has access to its own source of unbiased random-bits;
267: \item[\em (iii)]
268: The adversary is strong.
269: \end{itemize}
270: Then, there exist Las Vegas, wait-free consensus protocols for $n$
271: processes whose complexity is polynomial in expectation
272: and with high probability.
273: \end{theorem}
274: Notice that while Proposition~\ref{namImp} establishes the impossibility
275: of naming even against the weak adversary, here
276: the adversary is strong.
277:
278: Incidentally, Theorem~\ref{easyCon} shows that hypothesis~(iii) of
279: Proposition~\ref{namImp} is superfluos, for consensus objects
280: can be simulated via software in a wait-free manner.
281: It is well-known that hypothesis~(ii) is necessary, even if the adversary is weak
282: (see, for instance, \cite{lynch,aw}).
283: %All randomized consensus algorithms existing in the literature
284: %known (to the authors) assume
285: %either asymmetric memory or the existence of identifiers
286: %(see, for instance, \cite{aspnes,aspnes-herlihy,aspnes-waarts,chandra-toueg}).
287: %This result indicates that these assumptions are not necessary,
288: %for randomization alone suffices.
289:
290: In some sense naming captures the notion of complete asymmetry among the processes and
291: if we start from a completely symmetric situation it embodies the intuitive notion of
292: complete break of symmetry.
293: It is well-known that randomization is a powerful ``symmetry-breaker'' although, as
294: Proposition~\ref{namImp} shows, not enough for naming, if we start
295: from a perfectly symmetric situation.
296: This leads to the question of ``how much'' asymmetry is needed for naming.
297: Let us consider therefore asymmetric memory, assuming moreover
298: that processes do not have
299: access to the address (index) of their private registers. Formally,
300: each process $p$ accesses the $m$ registers by means of a permutation
301: $\pi_p$. Register $\pi_p^i$-- $p$'s $i$th register--
302: will always be the same register,
303: but, for $p \neq q$, $\pi_p^i$ and $\pi_q^i$ might very well differ.
304: In particular processes cannot obtain the physical address of the
305: registers. therefore the asymmetry is somehow hidden from the processes.
306: Although our motivation
307: is mainly theoretical, this model has been used to study
308: certain situations
309: in large dynamically changing systems where a consistent
310: indexing scheme
311: is difficult or impossible to maintain \cite{LP90}. Moreover
312: this model could make sense in
313: cryptographical systems where this kind of consistency is to be avoided.
314: %See \cite{pptv} for a justification of this formal setting.
315: %Each $p$ picks a random number $r$ between $1$ and $n^2$ and writes it in its
316: %own private register; $p$ reads the shared memory to look for the index
317: %of the register which contains $r$; if there is a unique such register,
318: %$p$ uses the index as its new ID; otherwise, $p$ picks a new number
319: %different from $r$ and repeats.
320:
321: We show the following.
322: If the memory is initialized to all 0's (or any other fixed value)
323: we say that it is initialized {\em fairly}.
324: \begin{proposition}\label{namImpAsym}
325: Assume that the memory is initialized fairly.
326: If processes are identical, deterministic i/o automata without
327: identifiers then naming is impossible, even if memory is asymmetric
328: and the adversary is weak.
329: \end{proposition}
330: Thus, by themselves, neither randomization nor asymmetric memory can break the symmetry.
331: What is needed is their acting together.
332: \begin{theorem}\label{asymMem}
333: Suppose that $n$ asynchronous processes \underline{without identifiers}
334: interact via a shared memory and that,
335: \begin{itemize}
336: \item[\em (i)]
337: Memory is asymmetric and initialized fairly;
338: \item[\em (ii)]
339: Each process has access to its own source of unbiased random-bits;
340: \item[\em (iii)]
341: The adversary is strong.
342: \end{itemize}
343: Then, there exist a Las Vegas, wait-free naming protocol for $n$
344: processes whose running time is polynomial in expectation.
345: Furthermore the key space from which identifiers
346: are drawn has size $n$, which is optimal.
347: \end{theorem}
348: Therefore, with randomization, asymmetric memory is inherently symmetry-breaking,
349: whereas consensus is not.
350:
351: This result improves on previous work in \cite{pptv} in which
352: naming protocols with almost-optimal key range are given.
353: We prove two versions of the above result. We first give a simple protocol whose running time
354: is $\Theta(n^2 \log n)$ w.h.p. and a faster protocol, named {\tt squeeze},
355: whose expected running time is $O(n \log^3 n)$.
356: As a by-product we also show that an object we call {\tt selectWinner}
357: cannot be implemented by consensus alone, i.e. without naming, even if randomization is available
358: and the adversary is weak. The semantics of {\tt selectWinner} is the following:
359: the object selects a unique winner among the invoking processes.
360:
361: Since any deterministic
362: protocol must use a key range of size at least $2n-1$ in order to be wait-free
363: \cite{HerS93}, this is yet another instance in which
364: randomization is more powerful than determinism
365: as far as fault-tolerant computing is concerned.
366:
367: Our results show, perhaps surprisingly, that
368: multiple reader - single writer registers are more powerful than
369: multiple reader - multiple writer registers, even though the latter
370: might represent a faster alternative.
371: This highlights an important difference
372: between the two models.
373:
374: Our Theorem~\ref{easyCon} is obtained by combining several
375: known ideas and protocols, in particular those in \cite{aspnes-herlihy} and
376: \cite{chandra}. When compared to the protocol in \cite{aspnes-herlihy} it is, we believe,
377: simpler, and its correctness is easier
378: to establish (see, for instance, \cite{segala}). Moreover, it works in the less
379: powerful symmetric model and
380: can deal with the strong adversary, whereas the protocol in \cite{chandra} can only withstand
381: the ``intermediate'' adversary, whose power lies somewhere between the more traditional
382: weak and strong adversaries we consider.
383: From the technical point of view, our Propositions~\ref{namImp} and~\ref{namImpAsym}
384: are essentially contained in \cite{kops} to which we refer for other interesting related results.
385: Other related work can be found in \cite{agm, jt}.
386:
387: In spite of the fact that we make use of several known technical ingredients,
388: our analysis, we believe, is novel and brings to light for the
389: first time new and, we hope, interesting aspects of fundamental concepts.
390:
391:
392:
393:
394:
395: % Rik's macros
396: \newcommand{\isp}{\hspace{0.7cm}}
397: \newcommand{\Mark}[2]{\mbox{{\sc Mark}{\rm [}$#1$, $#2${\rm ]}}}
398: \newcommand{\Coin}[2]{\mbox{{\sc GetCoin}$_{\delta}${\rm (}$#1$, $#2${\rm )}}}
399: \newcommand{\lr}{$\;\leftarrow\;$}
400: \newcommand{\estp}{\mbox{$myTeam_p$}}
401: \newcommand{\otherTeam}{\mbox{$otherTeam_p$}}
402: \newcommand{\nestp}{\mbox{$tentativeNewTeam_p$}}
403: \newcommand{\posp}{\mbox{$position_p$}}
404:
405:
406: \section{Consensus is Easy, Naming is Hard}
407: We start by outlining a consensus protocol
408: assuming that (a) the memory is symmetric, (b) processes are
409: i/o automata {\bf without} identifiers which have access to
410: their own source of (c) random bits.
411: Our protocol is obtained by combining together several known ideas
412: and by adapting them to our setting.
413: The protocol, a randomized implementation of $n$-process binary
414: consensus for symmetric memory, is a modification of the protocol
415: proposed by Chandra \cite{chandra}. The original protocol cannot be used in
416: our setting since its shared coins require that processes have
417: unique IDs. Thus, we combine it with a modification of the weak
418: shared coin protocol of Aspnes and Herlihy \cite{aspnes-herlihy}. The latter
419: cannot be directly used in our setting either, since it requires
420: asymmetric memory. Another difference is that, unlike in Chandra's protocol,
421: we cannot revert to Aspnes' consensus \cite{aspnes}.
422: In this paper we are only interested in establishing the existence of a
423: polynomial protocol and make no attempt at optimization.
424: Since the expected running time of our protocol is polynomial, by Markov's Inequality,
425: it follows that the running time and, consequently, the space used are
426: polynomial with high probability (inverse polynomial probability of failure).
427: Conceivably superpolynomial space could be needed. We leave it as an open
428: problem whether this is necessary.
429: % AP change
430: In the sequel we will assume familiarity with the notion
431: of weak shared coin of \cite{aspnes-herlihy} to which the reader is referred.
432:
433: The protocol, shown in Figure~\ref{fig:chandra}, is
434: based on the following idea. Processes engage in a race of sorts by splitting
435: into two groups: those supporting the 0 value and those supporting the
436: 1 value. At the beginning membership in the two ``teams'' is decided
437: by the input bits. Corresponding to each team there is a ``counter'',
438: implemented with a row of contiguous ``flags''-- the array of booleans \Mark{}{}-- which are to be raised
439: one after the other from left to right by the team members, cooperatively and asynchronously.
440: The variable \posp\ of each process $p$ records
441: the rightmost (raised) flag of its team the process knows about.
442: The protocol keeps executing the following loop, until a decision is
443: made. The current team of process $p$ is defined by the variable \estp.
444: The process first increments its own team counter by
445: raising the \posp-th flag of its own team (this might have already been
446: done by some other team member, but never mind). For instance, if $p$'s team corresponds to
447: the value $b$ then, \Mark{\posp}{b} is set to true.
448: Thus, as far as process $p$ is concerned, the value of
449: its own team counter is $position_p$ (of course, this might not
450: accurately reflect the real situation). The process then
451: ``reads'' the other counter by looking at the other team's row
452: of flags at positions $position_p+1, position_p, position_p-1$, in this order.
453: There are four cases to consider:
454: (a) if the other team is ahead the process sets the variable \nestp\
455: to the other team;
456: (b) if the two counters are equal, the process flips a fair coin
457: $X \in \{0,1\}$ by invoking the protocol \Coin{}{} and sets
458: \nestp\ to $X$;
459: (c) if the other team trails by one, the process sticks to its team, and
460: (d) if the other team trails by two (or more) the process decides
461: on its own team and stops executing the protocol.
462: The setting of \nestp\ is, as the name suggests, tentative.
463: Before executing the next iteration, the process checks again
464: the counter of its own team. If this has been changed in the meanwhile
465: (i.e. if the $({\posp}+1)$-st flag has been raised)
466: then the process sticks to his old team and continues; otherwise, it does
467: join the team specified by \nestp.
468: The array \Mark is implemented with {\tt multiple reader -
469: multiple writer} registers, while the other variables are local to each
470: process and accessible to it only. The local variables can assume only a finite (constant) set of
471: values and can therefore be ``hardwired'' in the states of the i/o automaton
472: representing the process.
473:
474: The only, but crucial, difference between our protocol and that of
475: Chandra concerns procedure \Coin{}{}.
476: In Chandra's setting essentially it is possible to implement
477: ``via software'' a {\em global coin}, thanks to the naming assumption
478: and the special assumption concerning the power of the adversary (``intermediate'' instead of
479: strong).
480: In the implementation in Figure~\ref{fig:chandra}, we use a protocol
481: for a weak shared coin for symmetric memory. For every
482: $b\in \{0,1\}$ and every $i \geq 1$ an independent realization of the
483: weak shared coin protocol is performed. An invocation of such a
484: protocol is denoted by \Coin{b}{i}, where $\delta$ is a positive real
485: that represents the agreement parameter of the weak shared coin
486: (see \cite{aspnes-herlihy}). \Coin{b}{i} satisfies th efollowing conditions.
487: Upon invocations with values $b$ and $i$, it returns 0 to all invoking
488: processes with probability $p \geq (1-\delta)/2$; it returns 1 to all invoking
489: processes with probability $p \geq (1-\delta)/2$; and, it returns 0 to some
490: and 1 to the others with probaility at most $\delta$ \cite{aspnes-herlihy}.
491:
492: \begin{figure}
493: \begin{center}
494: \hrule
495: \small
496: \begin{tabular}{ll}
497: \\
498: \multicolumn{2}{l}{{\tt \{}{\em Initialization}{\tt \}}}\\
499: \multicolumn{2}{l}{\Mark{0}{0}, \Mark{1}{0} \lr {\tt true}}\\
500: & \\
501: \multicolumn{2}{l}{{\tt \{}{\em Algorithm for process $p$}{\tt \}}}\\
502: & \\
503: \multicolumn{2}{l}{{\bf function} {\em propose}($v$): {\bf return}s 0 or 1}\\
504: 1. & \estp \lr $v$; \otherTeam \lr 1 - \estp\\
505: 2. & \posp \lr 1\\
506: 3. & {\bf repeat}\\
507: 4. & \isp \Mark{\estp}{\posp} \lr {\tt true}\\
508: 5. & \isp {\bf if} \Mark{\otherTeam}{\posp + 1}\\
509: 6. & \isp\isp \nestp \lr $1 - \estp$\\
510: 7. & \isp {\bf else if} \Mark{\otherTeam}{\posp}\\
511: 8. & \isp\isp \nestp \lr \Coin{\estp}{\posp}\\
512: 9. & \isp {\bf else if} \Mark{\otherTeam}{\posp - 1}\\
513: 10. & \isp\isp \nestp \lr \estp\\
514: 11. & \isp {\bf else return}(\estp) {\tt \{}{\em Decide} \estp{\tt \}}\\
515: 12. & \isp {\bf if not} \Mark{\estp}{\posp + 1}\\
516: 13. & \isp\isp \estp \lr \nestp\\
517: 14. & \isp \posp \lr $\posp + 1$\\
518: & {\bf end repeat} \\
519: \\
520: \end{tabular}
521: \hrule
522: \end{center}
523: \caption{$n$-process binary consensus for symmetric memory}
524: \label{fig:chandra}
525: %\label{sym-consensus}
526: \end{figure}
527:
528: First, we prove that the protocol in Figure~\ref{fig:chandra} is correct
529: and efficient. Later we show how to implement the weak shared coin.
530:
531: \begin{lemma}\label{sym-cons-valid}
532: If some process decides $v$ at time $t$, then, before time $t$ some process started
533: executing propose($v$).
534: \end{lemma}
535:
536: \begin{proof}
537: The proof is exactly the same of that of Lemma~1 in \cite{chandra}.
538: \end{proof}
539:
540: \begin{lemma}\label{sym-cons-consistent}
541: No two processes decide different values.
542: \end{lemma}
543:
544: \begin{proof}
545: The proof is exactly the same of that of case (3) of Lemma~4 in \cite{chandra}.
546: \end{proof}
547:
548: \begin{lemma}\label{sym-cons-shared}
549: Suppose that the following conditions hold:
550: \begin{description}
551: \item[{\em i)}] \Mark{b}{i} $=$ {\tt true} at time $t$,
552: \item[{\em ii)}] \Mark{1 - b}{i} $=$ {\tt false} before time $t$,
553: \item[{\em iii)}] \Mark{1 - b}{i} is set {\tt true} at time $t'$ ($t' > t$),
554: and
555: \item[{\em iv)}] every invocation of both \Coin{b}{i} and
556: \Coin{1 - b}{i} yields value $b$.
557: \end{description}
558: Then, no process sets \Mark{1 - b}{i + 1} to {\tt true}.
559: \end{lemma}
560:
561: \begin{proof}
562: The proof is essentially the same of that of the Claim included in
563: the proof of Lemma 6 in \cite{chandra}.
564: \end{proof}
565:
566: The next lemma is the heart of the new proof. The difficulty of course is that now
567: we are using protocol \Coin{}{} instead of the ``global coins'' of \cite{chandra}, and have
568: to contend with the strong adversary.
569: The crucial observation is that if two teams are in the same position $i$ and the adversary
570: wants to preserve parity between them, it must allow both teams to raise
571: their flags ``simultaneously,'' i.e. at least one teammate in each team must observe
572: parity in the row of flags. But then each team will proceed to invoke
573: \Coin{}{}, whose unknown outcome is unfavorable to the adversary
574: with probability at least $(\delta/2)^2$.
575:
576: \begin{lemma}\label{sym-cons-prob}
577: If \Mark{b}{i} $=$ {\tt true} at time $t$ and \Mark{1 - b}{i} $=$
578: {\tt false} before time $t$, then with probability at least $\delta^2/4$,
579: \Mark{1 - b}{i + 1} is always {\tt false}.
580: \end{lemma}
581:
582: \begin{proof}
583: If \Mark{1 - b}{i} is always {\tt false}, then it can be shown that
584: \Mark{1 - b}{i + 1} is always {\tt false} (the proof is the same of that
585: of Lemma~2 in \cite{chandra}). So, assume that \Mark{1 - b}{i} is set to
586: {\tt true} at some time $t'$ (clearly, $t' > t$). Since no invocation
587: of both \Coin{b}{i} and \Coin{1 - b}{i} is made before time $t$, the
588: values yielded by these invocations are independent of the schedule
589: until time $t$. Thus, with probability at least $\delta^2/4$,
590: all the invocations of \Coin{b}{i} and \Coin{1 - b}{i} yield
591: the same value $b$. From Lemma~\ref{sym-cons-shared}, it follows
592: that, with probability at least $\delta^2/4$, \Mark{1 - b}{i + 1} is
593: always {\tt false}.
594: \end{proof}
595:
596: \begin{theorem}\label{sym-cons-th}
597: The protocol of Figure~\ref{fig:chandra} is a randomized solution
598: to $n$-process binary consensus. Assuming that each invocation of \Coin{}{}
599: costs one unit of time, the expected running time per process
600: $O(1)$. Furthermore, with high probability every process will invoke
601: \Coin{}{} $O(\log n)$ many times.
602: \end{theorem}
603: \begin{proof}
604: From Lemma~\ref{sym-cons-consistent}, if any two processes decide, they
605: decide on the same value. From Lemma~\ref{sym-cons-valid} we know that the
606: decision value is the input bit of some process. We now show that all processes
607: decide within a finite number of steps and that this number is polynomial both
608: in expectation and with high probability.
609:
610: As regarding the expected decision time for any process, let $P(i)$ denote
611: the probability that there is a value $b \in \{0, 1\}$ such that
612: \Mark{b}{i} is always {\tt false}. From Lemma~\ref{sym-cons-prob},
613: it follows that
614: \[ P(i) \geq 1 - (1 - \delta^2/4)^{i - 1} \quad\quad i \geq 1 \]
615: Also, if \Mark{b}{i} is always {\tt false}, it is easy to see that
616: all the processes decide within $i + 1$ iterations of the {\bf repeat}
617: loop. Thus, with probability at least $1 - (1 - \delta^2/4)^{i - 1}$,
618: all the processes decide within $i+1$ iterations of the {\bf repeat}
619: loop. This implies that the expected running time per process is
620: {\rm O(1)}. The high probability claim follows from the observation that pessimistically
621: the process describing the invocations of \Coin{}{} can be modeled as a geometric distribution
622: with parameter $p := (\delta/2)^2$.
623: \end{proof}
624:
625: We now come to
626: the implementation of the weak shared coin for
627: symmetric memory,
628: which we accomplish via a slight modification of the
629: protocol of Aspnes and Herlihy \cite{aspnes-herlihy}.
630: In that protocol the $n$ processes cooperatively simulate a random walk
631: with absorbing barriers.
632: To keep track of the pebble a {\tt distributed counter} is employed. The distributed counter
633: is implemented with an array of $n$ registers, with position $i$ privately owned
634: by process $i$ (that is, naming or asymmetric memory is assumed). When process $i$ wants
635: to move the pebble it updates atomically its own private register
636: by incrementing or decrementing it by one. The private register
637: also records another piece of information namely, the number
638: of times that the owner updated it (this allows one to show that the implementation of the read is
639: linearizable). On the other hand, reading the position of
640: the pebble is a non-atomic operation. To read the counter the process scans
641: the array of registers twice; if the two scans yield identical values the read is completed,
642: otherwise two more scans are performed, and so on.
643: As shown in \cite{aspnes-herlihy}, the expected number of elementary operations
644: (read's and write's) performed by each process is $O(n^4)$.
645:
646: Since in our setting we cannot
647: use single-writer registers, we use an array {\sc C}[] of $n^2$
648: multiple-writer multiple-reader registers for the counter. The algorithm for
649: a process $p$ is as follows. Firstly, $p$ chooses uniformly at random
650: one of the $n^2$ registers of {\sc C}[], let it be the $k$th. Then,
651: the process proceeds with the protocol of Aspnes and Herlihy
652: by using {\sc C}[$k$] as its own register and by applying the counting
653: operations to all the registers of {\sc C}[]. Since we are using $n^2$ registers
654: instead of $n$, the expected number of steps that each process performs
655: to simulate the protocol is $O(n^5)$. The agreement parameter
656: of the protocol is set to $2e\delta$.
657: Since the expected number of rounds of the original protocol is {\rm O($n^4$)},
658: by Markov's Inequality, there is a
659: constant $B$ such that, with probability at least $1/2$, the protocol
660: terminates within $Bn^5$ rounds. It is easy to see
661: that if no two processes choose the same register,
662: then the protocol implements a weak shared coin with the same agreement
663: parameter of the original protocol in $O(n^5)$ many steps.
664: To ensure that our protocol will terminate in any case, if after $Bn^5$ steps the process has not yet
665: decided then it flips a coin and decides accordingly. Thus, in any case
666: the protocol terminates returning a value $0$ or $1$ to the calling process
667: within $O(n^5)$ steps. The probability that
668: no two processes choose the same register is
669: \[ \left(1 - \frac{1}{n^2}\right)\left(1 - \frac{2}{n^2}\right)\cdots
670: \left(1 - \frac{n - 1}{n^2}\right)
671: \geq \frac{1}{e}. \]
672: % AP change
673: Thus, the agreement parameter of our protocol is at least $1/2\cdot 1/e
674: \cdot 2e\delta = \delta$. We have proved the following fact.
675: \begin{lemma}
676: For any $\delta > 0$, a weak shared coin with agreement parameter
677: $\delta$ can be implemented in the symmetric model (with randomization)
678: in $O(n^5)$ steps, even against the strong adversary.
679: \end{lemma}
680: \begin{corollary}
681: The expected running time per process of the protocol of
682: Theorem~\ref{sym-cons-th} is $O(n^5)$.
683: \end{corollary}
684: \bigskip
685:
686:
687: We show next that, in contrast, no protocol exists in the symmetric model for naming, even assuming
688: the availability of consensus objects and the weak adversary.
689: \begin{theorem}\label{fact:namImp}
690: Suppose that an asynchronous, shared memory machine is such that:
691: \begin{itemize}
692: \item
693: the memory is symmetric;
694: \item
695: every process has access to a source of independent, unbiased random bits,
696: and
697: \item
698: consensus objects are available.
699: \end{itemize}
700: Then, still, naming is impossible even against a weak adversary.
701: \end{theorem}
702: \begin{proof}
703: By contradiction suppose there exist such a protocol.
704: Consider two processes P and Q and let only Q go. Since the protocol is wait-free
705: there exists a sequence of steps $\sigma=s_1 s_2 \ldots s_n $ taken by Q
706: such that Q decides on a name
707: $k_{\sigma}$. The memory goes through a sequence of states $m_0 m_1 \ldots m_n$.
708: The sequence $\sigma$ has a certain probability $p_{\sigma} = p_1 p_2 \ldots p_n$ of being
709: executed by Q. Start the system again, this time making both P and Q move, but one step at a time
710: alternating between P and Q. With probability $p_1^2$ both P and Q will make the same step $s_1$.
711: A simple case analysis performed on the atomic operations (read, write, invoke consensus)
712: shows that thereafter P and Q are in the same state and the shared memory
713: is in the same state $m_1$ in which it was when Q executed $s_1$ alone. This happens with probability
714: $p_1^2$. With probability $p_2^2$, if P and Q make one more step each, we reach a situation
715: in which P and Q are in the same state and the memory state is $m_2$.
716: And so on, until, with probability
717: $p_{\sigma}^2$ both P and Q decide on the same identifier, a contradiction.
718: \end{proof}
719:
720: Thus, naming is a necessary assumption in Herlihy's universality construction.
721:
722:
723: %The proof is omitted from this extended abstract.
724:
725:
726: %
727: %\begin{fact}
728: %If processes are identical, deterministic i/o automata without identifiers then
729: %Naming is impossible, even if memory is asymmetric and the adversary is weak.
730: %\end{fact}
731:
732:
733:
734:
735: \section{Naming with Asymmetric Memory}
736: We now come to the question of whether asymmetric memory can be used to
737: break the symmetry. First we show that by itself
738: it is not sufficient. Then we show that together with randomness
739: it allows naming to be solved in polynomial-time, using a key space of optimal size.
740:
741: \begin{proposition}
742: Suppose the memory is initialized fairly that is, all registers are initially set to 0
743: (or any other fixed value). Then,
744: if processes are identical, deterministic i/o automata without
745: identifiers, naming is impossible, even if memory is asymmetric
746: and the adversary is weak.
747: \end{proposition}
748:
749: \begin{proof}
750: Consider two processes $p$ and $q$ that are identical deterministic
751: i/o automata without identifiers. The shared memory is asymmetric:
752: processes $p$ and $q$ access the $n$ registers by means of
753: permutations $\pi_p$ and $\pi_q$. That is, when processor $p$ ($q$)
754: performs a {\tt Read($i$)} operation, the result will be the content
755: of the register having absolute index $\pi_p(i)$ ($\pi_q(i)$).
756: Analogously for the {\tt Write($i$, $v$)} operations. We assume that {\tt
757: Write($i$, $v$)} is legal only if $i \leq n/2$. That is, the local indices
758: of the private registers are $1,2,\ldots,n/2$.
759: We show the impossibility of naming even against the very simple
760: adversary with the alternating execution schedule:
761: $p$, $q$, $p$, $q$, $\ldots$
762: In this schedule the execution proceeds in rounds. Each round
763: consists of a step of $p$ followed by a step of $q$.
764:
765: We need some notions.
766: We call the map of the contents of all the registers, shared and
767: local, the absolute view. It is a function that maps each absolute
768: index $i$ to the content of the register of absolute index $i$.
769: Given an absolute view $V$ remains determined
770: the local views $L_p(V)$ and $L_q(V)$. The local view $L_p(V)$
771: is the map of the contents of the local registers of $p$ and
772: of the shared registers through the permutation $\pi_p$.
773: In other words, $L_p(V)$ is a function
774: that maps each local index $j$ to the content
775: of the register having local index $j$ w.r.t. the processor $p$.
776: In particular, if $j$ is a local
777: index of a shared register then the local view maps $j$ to the
778: content of the register of absolute index $\pi_p(j)$.
779: Analogously for the local view $L_q(V)$. We have already assumed that
780: the set of local indices of shared registers is
781: the same for both processors (i.e. the set $\{1,2,\ldots,n\}$).
782: We further assume that the set of local indices of
783: local registers is the same for both processors. Thus, the entire
784: set of local indices is the same for both processors. Therefore,
785: the domains of the two local views coincide.
786: An instant configuration, or simply a configuration, for processor
787: $p$ ($q$) is a pair $(L, s)$ where $L$ is a local view and $s$
788: is a state of $p$ ($q$).
789:
790: Let $s^p_t$ and $s^q_t$ be the states of $p$ and $q$, respectively,
791: at the beginning of round $t$.
792: Let $V_t$ be the absolute view at the
793: beginning of round $t$. We show that, for any $t$, if
794: the configurations $(L_p(V_t), s^p_t)$ and $(L_q(V_t), s^q_t)$
795: are equal then after the execution of round $t$ the resulting
796: configurations $(L_p(V_{t+1}), s^p_{t+1})$ and $(L_q(V_{t+1}), s^q_{t+1})$
797: are equal again.
798: This fact together with the assumption that the initial
799: configurations $(L_p(V_0), s^p_0)$ and $(L_q(V_0), s^q_0)$
800: are equal imply that the processes cannot select unique identifiers.
801:
802: Suppose that $(L_p(V_t), s^p_t)$ and $(L_q(V_t), s^q_t)$ are equal.
803: Since $s^p_t = s^q_t$ and the processes are identical deterministic
804: i/o automata, both processes execute the same operation {\tt op} at round $t$.
805: The operation {\tt op} can be a {\tt Read}, a {\tt Write}, or a local
806: operation.
807:
808: If {\tt op} is a {\tt Read($i$)} then, since $L_p(V_t)$ and $L_q(V_t)$
809: are equal, the processors read from different registers that have
810: equal contents. So, the changes to the local
811: registers are the same and the local views $L_p(V_{t+1})$ and $L_q(V_{t+1})$
812: are equal. Consequently, also the states $s^p_{t+1}$ and $s^q_{t+1}$
813: coincide.
814:
815: If {\tt op} is a {\tt Write($i$, $x$)} then, both processors write the same
816: value to different registers. But these registers have the same local
817: index. So, the next local views $L_p(V_{t+1})$ and $L_q(V_{t+1})$ are
818: equal again. Consequently, also the states $s^p_{t+1}$ and $s^q_{t+1}$
819: coincide.
820:
821: If {\tt op} is a local operation then, since {\tt op} and the local
822: memory is the same for both processors, the changes to the local
823: memories are the same and the local views $L_p(V_{t+1})$ and $L_q(V_{t+1})$ are
824: equal. Consequently, also the states $s^p_{t+1}$ and $s^q_{t+1}$
825: coincide.
826: \end{proof}
827:
828: Let us now turn to our naming protocol {\tt squeeze}.
829: For now, let us assume the availability of
830: objects {\tt selectWinner(i)} with the following semantics.
831: The object is invoked with a parameter $i$; the response is
832: to return the value {\em ``You own key $i$!''} to exactly one of the invoking processes,
833: and {\em ``Sorry, look for another key''} to all remaining processes. The choice of the ``winner''
834: is non-deterministic. Later we will show that {\tt selectWinner} admits
835: a wait-free, polynomial time Las Vegas solution
836: in our setting. With {\tt selectWinner} a naming protocol can be easily obtained
837: as follows: Try each key one by one, in sequence, each time invoking {\tt selectWinner}.
838: This protocol, dubbed {\tt simpleButExpensive}, is shown in Figure~\ref{fig:easyNaming}.
839: Therefore we obtain the following.
840: \begin{proposition}
841: Suppose that $n$ asynchronous processes \underline{without identifiers}
842: interact via a shared memory and that,
843: \begin{itemize}
844: \item[\em (i)]
845: Memory is asymmetric;
846: \item[\em (ii)]
847: Each process has access to its own source of unbiased random-bits;
848: \item[\em (iii)]
849: The adversary is strong.
850: \end{itemize}
851: Then, protocol {\tt simpleButExpensive} is a wait-free Las Vegas solution
852: to naming whose running time is polynomial in expectation and with high probability
853: \end{proposition}
854: The high probability statement follows from Lemma~\ref{lemma:selWinIter}.
855:
856: Although the overall running time of {\tt simpleButExpensive} is polynomial, given the high
857: cost of invoking {\tt selectWinner}
858: we turn our attention to protocol {\tt squeeze} which, in expecatation,
859: will only perform $O(\log^2 n)$ such invocations instead of linearly many.
860: \begin{figure}
861: \begin{center}
862: \small
863: \hrule
864: \tt
865: \begin{tabular}{l}
866: \\
867: protocol simpleButExpensive(): key; \\[.2cm]
868: begin \\
869: \ \ for k := 1 to n do \\
870: \ \ \ \ if selectWinner(k) = {\em ``You own key $k$!''} then return(k); \\
871: end \\
872: \\
873: \end{tabular}
874: \hrule
875: \end{center}
876: \caption{Simple but expensive protocol for naming}\label{fig:easyNaming}
877: \end{figure}
878:
879: In protocol {\tt squeeze}
880: the name space is divided into {\em segments},
881: defined by the following recurrence, where $p$ is
882: a parameter between 0 and 1 to be fixed later:
883: $$
884: s_{k} = p (1-p)^{k-1} n
885: $$
886: To simplify the presentation we assume without loss of generality that all $s_i$'s are integral.
887: $s_{\ell}$ is the last value $s_i$ such that $s_i \ge \log^2 n$.
888: The first segment consists of the key interval $I_1 := [0,s_1)$;
889: the second segment consists
890: of the key interval $I_2 := [s_1,s_1+s_2)$; the third of the key interval
891: $I_3 := [s_1+s_2,s_1+s_2+s_3)$, and so on. The final segment $I_{\ell+1}$ consists
892: of the last $n - \sum_{j=1}^{\ell} s_j$ keys.
893: In the protocol, each process $p$ starts by selecting a tentative key
894: $i$ uniformly at random in $I_1$.
895: Then, it invokes ${\tt selectWinner(i)}$;
896: if $p$ ``wins,'' the key becomes final and $p$ stops; otherwise,
897: $p$ selects a second tentative key $j$ uniformly at random in $I_2$. Again,
898: ${\tt selectWinner(j)}$ is invoked and if $p$ ``wins'' $j$ becomes final and $p$ stops, otherwise
899: $p$ continues in this fashion until $I_{\ell+1}$ is reached.
900: The keys of $I_{\ell+1}$ are tried one by one
901: in sequence. If at the end $p$ has no key yet, it will execute the
902: protocol {\tt simpleButExpensive} of Figure~\ref{fig:easyNaming} as a
903: back-up procedure.
904: The resulting protocol appears in Figure~\ref{fig:squeeze}.
905:
906: Assuming the availability of objects of type {\tt selectWinner}, protocol
907: {\tt squeeze} assigns a key to every non-faulty process with probability 1. This
908: follows, because the protocol ensures that {\tt selectWinner(i)} is invoked for every
909: $i$, $1 \le i \le n$,
910: and each such invocation assigns a key to exactly one process.
911: We will now argue that with high probability every process receives a unique key
912: before the back-up procedure, and that therefore the number of invocations of
913: {\tt selectWinner} objects is $O(\log^2 n)$ per process w.h.p..
914:
915:
916: Protocol {\tt squeeze} maintains the following invariant (w.h.p.).
917: Let $P_k$ be the set of processes that after $k-1$ attempts still have to grab a key.
918: Their $k$-th attempt will be to select a key at random in segment $I_k$. Then,
919: $|P_k| \approx |I_k| \log n \gg |I_k|$ (hence the protocol ``squeezes'' $P_k$
920: into $I_k$). Once the numbers are plugged in it follows that, with high probability,
921: every key in $I_k$ will be claimed by some process, and this for all $k$. Since
922: every key is claimed w.h.p. before the back-up procedure, every process, w.h.p.,
923: receives a key within $O(\log^2 n)$ invocations of {\tt selectWinner}.
924: By setting the parameter $p$ appropriately it is possible to keep
925: the number of segments small, i.e. $O(\log^2 n)$, while maintaining
926: the invariant $|P_k| \gg |I_k|$ for each segment.
927:
928: Let us focus first on a run without crashes.
929: Let $p_i$ be defined by the following recurrence
930: $$
931: p_i := (1-p)^{i-1} n.
932: $$
933: Clearly, $|P_i| \ge p_i$.
934: We want to show that, with high probability, $|P_i| = p_i$, for $i < \ell$.
935: If we can show this we are done because then $p_{\ell} = s_{\ell}$ and
936: the protocol ensures that every one of the remaining $p_{\ell}$ process
937: will receive one of the last $s_{\ell}$ keys.
938: A key $k$ is {\em claimed} if {\tt selectWinner(k)} is invoked by some process.
939: %Given any execution of the protocol, define $r_i$ to be the number of processes
940: %which perform the $i$-th attempt, and let $c_i$ denote the number of processes
941: %which crash prior to performing their $i$th attempt.
942: %\begin{eqnarray*}
943: %r_{k+1}
944: %& = & r_k - c(r_k,k) - \mbox{\small ($\#$ processes crashed while performing $k$th attempt}) \\
945: %& \le & p_k - c(p_k,k) - \mbox{\small ($\#$ processes crashed while performing
946: %$k$th attempt}) \\
947: %& \le & p_k - c(p_k,k)
948: %\end{eqnarray*}
949: % AP change
950: Then, since there are no crashes,
951: $$
952: \Pr[\mbox{$\exists k \in I_i$, $k$ not claimed}]
953: \le \left(1 - \frac{1}{s_i} \right)^{p_i}
954: \le \exp \left\{- \frac{s_i}{p_i} \right\}
955: \le \exp \left\{- \frac{1}{p} \right\}
956: = \frac{1}{n^c}
957: $$
958: for any fixed $c > 0$, provided that
959: $$
960: p := \frac{1}{c \log n}.
961: $$
962: With this choce of $p$ the number of segments $\ell$ is $O(\log^2 n)$.
963: The expected running time is therefore
964: $$
965: E[T(n)] = O(\log^2 n) (1-\ell/n^{c}) + O(n) \ell/n^{c} = O(\log^2 n)
966: $$
967: for $c > 3$.
968:
969: We now argue that with crashes the situation can only improve.
970: Let $C_1$ be the set of processes that crash before obtaining
971: a response to their invocation of {\tt selectWinner} in $I_1$.
972: Let $F_1$ (F as in free) be the set of keys of $I_1$ that are not
973: claimed after processes in $P_1$ have made their
974: random choice. If $F_1$ is non empty, assign
975: processes of $C_1$ to keys of $F_1$ in a one-to-one fashion. Let $f_1$ be this map.
976: Then, the probability that a key
977: is claimed before any process under this new scheme is no lower than in a run without crashes.
978: We then set $C_2$ to be the set of processes of $P_2$ that crashed before
979: obtaining a response for their invocation of {\tt selectWinner} in $I_2$, union
980: $C_1 - f_1(C_1)$. Again, after processes in $P_2$ randomly select keys in $I_2$,
981: assign processes of $C_2$ to keys of $F_2$ by means of a one-to-one function $f_2$. Thus, again,
982: the probability that a key in $I_2$ is claimed is higher than in a run without crashes.
983: And so on.
984: Thus, we have the following.
985:
986: \begin{lemma}
987: The expected number of invocations of {\tt selectWinner} per process in protocol {\tt squeeze}
988: is $O(\log^2 n)$.
989: \end{lemma}
990:
991: It remains to show how to implement {\tt selectWinner} in a wait-free manner
992: in polynomial time.
993: We will assume the availability of objects of type {\tt consensus(i,b)} where $1 \le i \le n$
994: and $b \in \{0,1\}$. Each invoking process $p$ will perform the invocation using the two
995: parameters $i$ and $b$; the object response will be the same to all processes
996: and will be {\em ``The consensus value for $i$ is $v$''} where $v$ is one of the bits
997: $b$ that were proposed. By Theorem~\ref{sym-cons-th}
998: the availability of consensus objects can be assumed without loss of generality.
999: Assuming them will simplify the presentation.
1000: The protocol for {\tt selectWinner}, shown in Figure~\ref{fig:select}, is as follows.
1001: Each process $p$ generates a bit $b_1^p$ at random and invokes {\tt consensus(1,$b_1^p$)}.
1002: Let $v_1$ be the response of the consensus object. If $b_1^p \neq v_1$ then $p$ is a {\em loser} and
1003: exits the protocol. Otherwise, $p$ is still in the game. Now the problem is to ascertain whether
1004: $p$ is alone, in that case it is the {\em winner}, or if there are other processes still in the game.
1005: To this end, each remaining process scans the array $W[1,i]$, for $1 \le i \le n$, that is initialized
1006: to all 0's. If $W[1,i]$ contains a 1 then $p$ declares itself a {\em loser} and exits;
1007: otherwise it writes a 1 in its private position $W[1,p]$ and scans $W[1,-]$ again.
1008: If $W[1,-]$ contains a single 1, namely $W[1,p]$ then $p$ declares itself the {\em winner}
1009: and grabs the key, otherwise it continues the game that is, it generates a second bit $b_2^p$
1010: at random, invokes {\tt consensus(2,$b_2^p$)}, and so on.
1011: The following observations and lemma establish the correctness of the protocol.
1012:
1013: \begin{observation}
1014: If $p$ declares itself the winner then it is the only process to do so.
1015: \end{observation}
1016:
1017: \begin{observation}
1018: There is always a process that declares itself the winner.
1019: \end{observation}
1020:
1021: \begin{lemma}\label{lemma:selWinIter}
1022: With probability
1023: $1-o(1)$, every process $p$ generates $O(\log n)$ many random bits $b_i^p$
1024: and the number of bit operations per process is $O(n \log n)$.
1025: \end{lemma}
1026: \begin{proof}
1027: We refer to an iteration of a repeat loop of protocol {\tt selectWinner} as a {\em round},
1028: i.e. the round $i$ refers to the
1029: set of iterations of the repeat loop in which the participating processes
1030: toss their private coin for the $i$th time.
1031: We assume pessimistically that the consensus object of protocol {\tt selectWinner} is under the
1032: control of the strong adversary, subject to the following rules. Denoting with
1033: $1, \ldots, k$ the processes that perform the $i$th coin toss,
1034: If $<b_i^1 = b_i^2 = \ldots = b_i^k = 0$ or
1035: $<b_i^1 = b_i^2 = \ldots = b_i^k = 1$ then the adversary can respond with consensus value
1036: 0 or 1, respectively. Otherwise the adversary can respond with any value.
1037:
1038: The goal of the adversary is to maximize the number of rounds. Therefore
1039: its best policy is to return the consensus value that eliminate the smallest number
1040: of processes, i.e. the best strategy is to return the majority bit.
1041: The probability that the $i$th outcome of process $p$ is the majority value
1042: depends on the number of processes, but it is easily seen to be maximized when there
1043: are two processes.
1044: The probability that the minority value is the outcome of at least $1/4$
1045: of the processes depends on the number of processes, but it is monotonically decreasing.
1046: Therefore the smallest value is $1/4$, when just 2 processes are involved.
1047:
1048: We call a run {\em successful} if the minority value is the outcome of at least $1/4$
1049: of the processes. Then, $\log_{4/3} n$ many successful rounds suffice to select a winner.
1050: A straightforward application of the Chernoff-Hoeffding bounds
1051: show that with probability $1-o(1)$ at least $\log_{4/3} n$ rounds out of $8 \log_{4/3} n$
1052: many will be successful.
1053:
1054: Since every iteration of {\tt selectWinner} costs $O(n)$ steps, the claim follows.
1055: \end{proof}
1056:
1057: \begin{theorem}
1058: Protocol {\tt squeeze} is a Las Vegas, wait-free naiming protocol for asymmetric memory
1059: whose running time is $O(n^2 \log n)$ with probability $1 - o(1)$.
1060: \end{theorem}
1061:
1062: \noindent
1063: {\bf Remark 1:} Protocol {\tt squeeze} is also a good renaming protocol.
1064: Instead of the random bits, each process can use the bits of its own IDs starting, say, from the
1065: left hand side.
1066: Since the ID's are all different the above scheme will always select a unique winner
1067: within $O(|ID|)$ invocation of consensus.
1068: \bigskip
1069:
1070: \noindent
1071: {\bf Remark 2:} The only part of protocol {\tt squeeze} that actually uses the
1072: memory is protocol {\tt selectWinner}. In view of Proposition~\ref{fact:namImp} this task
1073: must be impossible with symmetric memory, even if randomness and consensus are available.
1074: Thus, this is another task for which, strictly speaking, Herlihy's result does
1075: not hold and it is another
1076: example of something that cannot be accomplished by the power of randomization alone.
1077:
1078:
1079:
1080:
1081:
1082: %\begin{figure}
1083: %\begin{center}
1084: %\small
1085: %\hrule
1086: %\tt
1087: %\begin{tabular}{l}
1088: %\\
1089: %protocol simpleButExpensive(): key; \\[.2cm]
1090: %begin \\
1091: %\ \ for k := 1 to n do \\
1092: %\ \ \ \ if selectWinner(k) = {\em ``You own key $k$!''} then return(k); \\
1093: %end \\
1094: %\\
1095: %\end{tabular}
1096: %\hrule
1097: %\end{center}
1098: %\caption{Simple but expensive protocol for naming}\label{fig:easyNaming}
1099: %\end{figure}
1100:
1101: \begin{figure}
1102: \begin{center}
1103: \small
1104: \hrule
1105: \tt
1106: \begin{tabular}{l}
1107: \\
1108: protocol squeeze(): key; \\[.2cm]
1109: begin \\
1110: \ \ for i := 1 to $\ell$ do begin \\
1111: \ \ \ \ k := random key in interval $I_i$; \\
1112: \ \ \ \ if selectWinner(k) = {\em ``You own key $k$!''} then return(k); \\
1113: \ \ \ \ end; \\
1114: \ \ for k := n - $s_{\ell}$ to n do \hfill \{try key in $I_{\ell}$ one by one\} \\
1115: \ \ \ \ if selectWinner(k) = {\em ``You own key $k$!''} then return(k); \\
1116: \ \ return(simpleButExpensive()) \hfill \{back up procedure\} \\
1117: end \\
1118: \\
1119: \end{tabular}
1120: \hrule
1121: \end{center}
1122: \caption{Protocol squeeze}\label{fig:squeeze}
1123: \end{figure}
1124:
1125:
1126:
1127: \begin{figure}
1128: \begin{center}
1129: \small
1130: \tt
1131: \hrule
1132: \begin{tabular}{l}
1133: \\
1134: protocol selectWinner(i: key): outcome; \\
1135: \\
1136: myReg := ``private register of executing process''; \\
1137: attempt := 1; \\
1138: repeat \\
1139: \ \ b := random bit; \\
1140: \ \ if (b = consensus(i, b)) then begin \\
1141: \ \ \ \ scan W[attempt,j] for $1 \le j \le n$; \\
1142: \ \ \ \ if (W[attempt,j] = 0, for all j) then begin \\
1143: \ \ \ \ \ \ W[attempt,myReg] := 1; \\
1144: \ \ \ \ \ \ scan W[attempt,j] for $1 \le j \le n$; \\
1145: \ \ \ \ \ \ if (W[attempt,j] = 0, for all j <> myReg) then return(i); \hfill \{key
1146: is grabbed!\} \\
1147: \ \ \ \ \ \ else attempt := attempt + 1; \hfill \{keep trying\} \\
1148: \ \ \ \ else return({\em ``Sorry, look for another key.''}); \\
1149: end repeat \\
1150: \\
1151: \end{tabular}
1152: \hrule
1153: \end{center}
1154: \caption{Protocol selectWinner}\label{fig:select}
1155: \end{figure}
1156:
1157:
1158:
1159:
1160:
1161:
1162:
1163:
1164:
1165:
1166:
1167:
1168: \begin{thebibliography}{99}
1169:
1170: \bibitem{aspnes}
1171: J. Aspnes,
1172: Time- and space-efficient randomized consensus.
1173: Journal of Algorithms 14(3):414-431, May 1993.
1174:
1175: \bibitem{aspnesLB}
1176: J. Aspnes,
1177: Lower bounds for distributed coin-flipping and randomized consensus.
1178: Journal of the Association for Computing Machinery 45(3):415-450, May
1179: 1998.
1180:
1181: \bibitem{aspnes-herlihy}
1182: J. Aspnes and M.Herlihy,
1183: Fast randomized consensus using shared memory,
1184: Journal of Algorithms 11(3):441-461, September 1990.
1185:
1186: \bibitem{aspnes-waarts}
1187: J. Aspnes and O.Waarts,
1188: Randomized consensus in $O(n \log n)$ operations per processor,
1189: SIAM Journal on Computing 25(5):1024-1044, October 1996.
1190:
1191: \bibitem{agm}
1192: A. Attiya, Gorbach, S. Moran,
1193: Computing in totally anonymopus shared memory systems, DISC 98, LNCS 1499,
1194: pp. 49--61
1195:
1196: \bibitem{aw}
1197: H. Attiya e J. Welch, Distributed Computing, McGraw-Hill
1198:
1199: \bibitem{aumann}
1200: Y. Aumann,
1201: Efficient Asynchronous Consensus with the Weak Adversary Scheduler,
1202: in Proceedings of the 16th ACM SIGACT-SIGOPS
1203: Symposium on Principles of Distributed Computing (PODC 1997), pp. 209-218
1204:
1205: \bibitem{BarD89}
1206: A. Bar-Noy and D. Dolev,
1207: Shared Memory vs. Message-passing in an Asynchronous Distributed
1208: Environment.
1209: In {\em Proceedings of the 8th ACM Symposium on Principles of Distributed
1210: Computing}, 1989, pp.~307--318.
1211:
1212: \bibitem{BorG93}
1213: E. Borowsky and E. Gafni,
1214: Immediate Atomic Snapshots and Fast Renaming.
1215: In {\em Proceedings of the 12th ACM Symposium on Principles of Distributed
1216: Computing}, 1993, pp.~41--52.
1217:
1218: \bibitem{chandra}
1219: T. D. Chandra,
1220: Polylog Randomized Wait-Free Consensus,
1221: in Proceedings of the 15th ACM SIGACT-SIGOPS
1222: Symposium on Principles of Distributed Computing
1223: (PODC 1996)
1224:
1225: \bibitem{cht}
1226: T. D. Chandra, V. Hadzilacos, and S. Toueg.
1227: The weakest failure detector for solving Consensus.
1228: Journal of the ACM, 43(4):685-722, July 1996.
1229:
1230: \bibitem{chandra-toueg}
1231: T. D. Chandra and S. Toueg,
1232: Unreliable failure detectors for reliable distributed systems.
1233: Journal of the ACM, 43(2):225-267, March 1996.
1234:
1235: \bibitem{herlihy}
1236: M. Herlihy,
1237: Wait-Free Synchronization,
1238: preliminary version in Proceedings of the 7th ACM SIGACT-SIGOPS
1239: Symposium on Principles of Distributed Computing (PODC 1988)
1240:
1241: \bibitem{HerS93}
1242: M. Herlihy and N. Shavit,
1243: The Asynchronous Computability Theorem for $t$\/-Resilient Tasks.
1244: In {\em Proc. 25th ACM Symp. Theory of Computing},
1245: 1993, pp.~111--120.
1246:
1247: \bibitem{jayanti}
1248: P. Jayanti,
1249: Robust wait-free hierarchies.
1250: Journal of the ACM, 44(4):592-614, July 1997.
1251:
1252: \bibitem{jt}
1253: P. Jayanti and S. Toueg,
1254: Wake-up under read/write atomicity, WDAG 1990, LNCS 486, pp. 277--288.
1255:
1256:
1257: \bibitem{kops}
1258: S. Kutten, R. Ostrovsky and B. Patt-Shamir.
1259: The Las-Vegas Processor Identity Problem (How and When to Be Uniique),
1260: Proceedings of the 1st Israel Symposium on Theory of Computing
1261: and Systems, 1993.
1262:
1263: \bibitem{LP90}
1264: R.J. Lipton and A. Park, Solving the processor identity problem
1265: in $O(n)$ space, {\em Inform. Process. Lett.}, 36(1990), 91--94.
1266:
1267: \bibitem{lo-hadz}
1268: Wai-Kau Lo and V. Hadzilacos.
1269: Using Failure Detectors to Solve Consensus in Asynchronous Shared-Memory
1270: Systems, Proceedings of the 8th International Workshop on Distributed
1271: Algorithms. Terschelling, The Netherlands, September--October 1994,
1272: pp.~280--295.
1273:
1274: \bibitem{lynch}
1275: N. Lynch, Distributed Algorithms, Morgan Kaufmann
1276:
1277:
1278: \bibitem{pptv}
1279: A. Panconesi, M. Papatriantafilou, P. Tsigas and P. Vitanyi,
1280: Randomized naming using wait-free shared variables.
1281: Distributed Computing (1998) 11:113--124
1282:
1283: \bibitem{segala}
1284: A. Pogosyants, R. Segala and Nancy Lynch,
1285: Verification of the Randomized Consensus Algorithm of Aspnes and
1286: Herlihy: a Case Study,
1287: MIT Technical Memo number MIT/LCS/TM-555, June 1997.
1288:
1289:
1290: \end{thebibliography}
1291:
1292: \end{document}
1293:
1294:
1295:
1296:
1297:
1298:
1299:
1300:
1301: