k-abortable Objects: Progress Under High Contention

Transcription

1 k-abortable Objects: Progress Under High Contention Naama Ben-David 1, David Yu Cheng Chan 2(B), Vassos Hadzilacos 2, and Sam Toueg 2 1 Carnegie Mellon University, Pittsburgh, PA 15213, USA naama@cmu.edu 2 University of Toronto, Toronto, ON M5S1A1, Canada {davidchan,vassos,sam}@cs.toronto.edu Abstract. In this paper, we define k-abortable objects, the first kind of abortable objects [2, 7] that guarantee some degree of progress even under high contention. The definition is simple and natural: intuitively, an operation on a k-abortable object can abort only if k operations from distinct processes succeed during the execution of the aborted operation. We first show that k-abortable objects can easily implement k-lock-free objects, i.e., objects where at least k processes make progress [5], but in contrast to k-lock-free objects, k-abortable objects always return control. We then give an efficient universal construction for wait-free k-abortable objects shared by n processes that takes only O(k) steps per operation. We also give a Ω(log k)-steps lower bound for universal constructions of k-abortable objects shared by n k processes. Since every wait-free k-abortable object can implement its k-lock-free counterpart, our universal construction also provides a universal construction for k-lock-free objects. Keywords: Shared memory Lock-freedom Wait-freedom Distributed algorithms Abortable objects Liveness conditions Asynchronous system 1 Introduction Motivation and Related Work. We consider asynchronous distributed systems where processes apply operations to linearizable shared objects [10]. A liveness property specifies the conditions under which processes make progress, i.e., the conditions under which the operations that they apply to the shared objects return a response. A strong liveness property is wait-freedom [8], which guarantees that all correct processes make progress. This is an attractive property, but wait-free objects are often difficult and inefficient to implement, and so several weaker liveness properties have been suggested. N. Ben-David Part of this work was done while the author was at the University of Toronto. c Springer-Verlag Berlin Heidelberg 2016 C. Gavoille and D. Ilcinkas (Eds.): DISC 2016, LNCS 9888, pp , DOI: /

2 k-abortable Objects: Progress Under High Contention 299 One such property is lock-freedom, which guarantees that at least one correct process makes progress (this property is also called non-blocking). Many concurrent data structures are implemented in a lock-free manner [4, 13]. Bushkov and Guerraoui recently defined k-lock-freedom [5], which, roughly speaking, guarantees that at least k correct processes make progress. This generalization of lock-freedom is appealing because when k ranges from 1 to n, k-lock-freedom goes from lock-freedom all the way to wait-freedom. Prior to the present paper, for k>1, there was no implementation of any k-lock-free object that was not also wait free. Another weak liveness property is obstruction-freedom [9]: if a process applies an operation to an obstruction-free object, and it eventually runs alone for sufficiently many steps, then this operation terminates. One advantage of obstruction-freedom is that any obstruction-free data structure can be implemented purely from registers, so there is no need for stronger, more expensive primitives. But if there are two (or more) processes that take steps concurrently, all of them can be stuck forever inside an object. To strengthen obstructionfreedom, Taubenfeld [14] defines k-obstruction freedom: if processes apply operations to a k-obstruction-free object, and a group of up to k of them eventually run alone for sufficiently many steps, then the operations of this group terminate. Note that with k-lock-freedom and k-obstruction freedom, a correct process may get stuck, i.e., it may apply an operation that never returns. 1 This motivates the idea of always returning from an operation at the cost of sometimes returning with an exception. Early work in this direction focused on objects that can be implemented from registers alone: [3] allows concurrent operations to return pause (in which case, they must be resumed), and [2] allows concurrent operations to return abort, in which case they may or may not have taken effect. More recent work [7] introduced a stronger type of abortable objects, called deterministic abortable objects, where it is guaranteed that aborted operations do not take effect. With such objects, a process that applies an operation that aborts is free to do some other work before safely retrying this operation (because it knows that the previous attempt did not have any effect), or to attempt other alternatives if possible. 2 The abortable objects defined in [2, 7], however, have a serious drawback: when processes are concurrently active no progress is guaranteed. This is because an operation op may abort even if it is concurrent with only one other operation op, and, symmetrically, op may also abort. A similar problem also affects pausable objects [3]. Contributions of this Paper. In this paper, we introduce k-abortable objects, the first kind of abortable objects that guarantee some degree of progress even 1 This is akin to entering a bakery and getting stuck inside forever, because other customers keep cutting in line. 2 This is akin to entering a bakery and being notified that it is currently too busy; the customer is now free to do other errands and come back later, when the bakery may be less busy, or to go to another bakery.

3 300 N. Ben-David et al. under high contention. This progress guarantee is achieved by strengthening the conditions under which concurrent operations can abort, as follows: 1. An operation op can abort only if it is concurrent with at least k other operations; moreover, these k operations must be executed by distinct processes. 3 This requirement ensures that if at most k processes are active, no operation aborts, and so all the processes make progress. But if more than k processes are active, this property alone does not guarantee any progress because all operations can abort. Thus we also require the following property. 2. The k operations that cause an operation op to abort must themselves succeed; moreover, they must take effect during op s execution interval. 4 This requirement ensures that if more than k processes are active, at least k of them make progress. Together, the above two requirements can be stated in a more precise and succinct way as follows: an operation op may abort only if at least k operations by distinct processes do not abort and are linearized within op s execution interval. As in [7], k-abortable objects also have the property that aborted operations are guaranteed not to take effect. After defining k-abortable objects, we compare them to k-lock-free objects and show that every k-abortable object can implement a k-lock-free object of the same type (so every 1-abortable object can implement its lock-free counterpart). We then investigate whether, in general, k-abortable objects can be implemented more efficiently than their wait-free counterparts. To do so, we give an efficient universal construction for k-abortable objects shared by n processes that takes only O(k) steps per operation and uses only LL/VL/SC base objects. 5 In contrast, Jayanti has shown a lower bound of Ω(log n) steps for universal constructions of wait-free objects shared by n processes [11], and this lower bound holds for shared-memory that supports LL/VL/SC, move and swap operations. Therefore, in such systems, k-abortable objects can be implemented more efficiently than their wait-free counterparts when k = o(log n). Furthermore, all the known universal constructions of wait-free objects require Ω(n) steps per operation in the worst case, except for those that make impractical assumptions on the size of registers (such as registers that can hold n operations) [6,11]. Our universal construction of k-abortable objects does not make such assumptions; the effect of these assumptions is further discussed in Sect. 6. Finally, we show an Ω(log k)-steps lower bound for universal constructions of k-abortable objects shared by n k processes in systems with LL/VL/SC objects (we do so by using Jayanti s lower bound for wait-free universal constructions). This leaves an interesting open problem, namely closing the gap between the Ω(log k) lower bound and the O(k) upper bound given by our universal construction. This mirrors another open problem [11], namely closing the 3 So op cannot abort just because it is concurrent with k operations of a fast process. 4 So they cannot cause operations that start after op to abort. 5 In general, k-abortable objects require strong primitives because they can implement their lock-free counterparts.

4 k-abortable Objects: Progress Under High Contention 301 gap between the Ω(log n) lower bound and the O(n) upper bound for universal constructions of wait-free objects that do not make impractical assumptions on the size of registers [11]. An important remark about adaptive implementations [1] and their relation to k-abortable implementations is now in order. Afek et al. presented an adaptive wait-free universal construction called Individual Update [1] that takes only O(l) steps per operation, where l is the number of processes that access the object concurrently. When contention is high, l can increase all the way up to n, and in this case adaptive implementations are just as expensive as conventional wait-free implementations. In contrast, our universal construction for k-abortable objects never takes more than O(k) steps per operation, at the cost of allowing some operations to abort. Note that the concepts of adaptivity and abortability are not mutually exclusive: a k-abortable object could have an adaptive implementation that runs in O(min(l, k)) time, where l is the number of processes that access the object concurrently. Adaptivity and k-abortability are also compared in Sects. 4 and 6. In summary, our main contributions are: 1. We define k-abortable objects, the first kind of abortable objects that guarantee some degree of progress even under high contention. The definition is simple and natural: intuitively, an operation on a k-abortable object can abort only if k operations from distinct processes succeed during the execution of the aborted operation. 2. We show that every k-lock-free object can be implemented by a single instance of a k-abortable object of the same type. Recall that, in contrast to k-lockfree objects where some processes may get stuck, k-abortable objects always return control. 3. We give a universal construction for wait-free k-abortable objects shared by n processes that takes only O(k) steps per operation: for k = o(log n), this beats the well-known lower bound of Ω(log n) steps per operation for universal constructions of wait-free objects [11]. This is also significantly better than the O(n) steps per operation required by known practical universal constructions of wait-free objects. 4. Since every k-abortable object can implement its k-lock-free counterpart, our universal construction also provides a universal construction for k-lock-free objects. Prior to our work, for k>1, there was no implementation of any k-lock-free object, except for ones that are also wait free (and therefore incur the cost of achieving wait freedom). 5. Finally, we show that Jayanti s Ω(log n)-steps lower bound for wait-free universal constructions implies an analogous Ω(log k)-steps lower bound for universal constructions of k-abortable objects shared by n k processes. 2 Model Sketch We adopt a standard model for systems with asynchronous processes and shared objects, with a minor extension to describe abortable objects (this model is similar to the one in [7]).

5 302 N. Ben-David et al. Steps and Histories. Each process p executes steps, which are of two kinds: the invocation by p of an operation op on an object O, denoted (inv,p,op,o); and the receipt by p of a response res from an object O, denoted (res,p,res,o). A history H of an object is a sequence of invocation and response steps, such that: for each process p, the subsequence of H involving only the steps of p consists of zero or more pairs of invocation and response steps (the two steps of each pair are called matching), possibly followed by an invocation step. An operation execution opx in a history H of an object is either a pair consisting of an invocation and its matching response in H, in which case we say that opx is complete in H; or an invocation in H that has no matching response in H, in which case we say that opx is incomplete or pending in H. A history H is complete if all operation executions in H are complete. A completion of H is a history H formed by removing invocations or adding responses to every pending operation execution in H, such that H is complete. Object Types and Linearizability. Each object has a type that specifies how the object behaves when it is accessed sequentially. Formally, an object type T is specified by a tuple (OP, RES,Q,δ), where OP is a set of operations, RES is a set of responses, Q is a set of states, and δ Q OP Q RES is a state transition relation. A tuple (s, op,s, res) inδ means that if type T is in state s when operation op OP is invoked, then T can change its state to s and return the response res. For each type T =(OP, RES,Q,δ), we define the abortable counterpart T of T. 6 Intuitively, type T is the same as T, except that every operation is allowed to abort, making no change to the state and terminating with a special response. More precisely, T =(OP, RES a,q,δ a ) where RES a = RES { } for some / RES, and, for every tuple (s, op,s, res) in the state transition relation δ of T, the state transition relation δ a of T contains both (s, op,s, res) and (s, op,s, ): the first tuple corresponds to op completing normally as it does in T, and the second corresponds to op aborting without changing the state. When an object O of type T is accessed concurrently, its behaviour should be linearizable with respect to T : every operation on O must appear to take effect instantaneously, at some point during the operation s execution interval, according to type T [10]. More precisely, a linearization L of a complete history H of an object is an assignment of a distinct linearization point L(opx) toevery operation execution opx in H such that L(opx) is within the execution interval of opx in H. A linearization L of a complete history H of an object conforms to type T, if the operation responses in H could be those received when applying these operations sequentially, in the order dictated by L, on an object of type T. A history H of an object is linearizable with respect to a type T if H has a completion H and a linearization L of H that conforms to type T. An object O is linearizable with respect to a type T if every history H of O is linearizable with respect to type T. 6 This was originally called the deterministic abortable counterpart of a type T in [7].

6 k-abortable Objects: Progress Under High Contention 303 k-abortable Objects. Intuitively, O is a k-abortable object of type T if: (1) O behaves like an object of type T except that operations may also abort (aborted operations have no effect), and (2) for each operation opx that aborts, there are k operations from distinct processes that do not abort and take effect within opx s interval. More precisely, an object O is a k-abortable object of type T if, for every history H of O, there is a completion H and a linearization L of H such that: (1) the linearization L of H conforms to the abortable counterpart T of T, and (2) for each operation execution opx that aborts in H, there are k operations from distinct processes that do not abort in H and whose linearization point L (opx) is within the execution interval of opx in H. Note that in a system with n processes, an n-abortable object of type T is just an object of type T. An (implementation of a) k-abortable object of type T is wait-free if a process cannot invoke an operation on O and then take infinitely many steps without receiving a response from O. Henceforth, we consider only waitfree (implementations of) k-abortable objects, and by k-abortable O we mean wait-free k-abortable O. Thus, n-abortable objects are wait-free objects. 3 Relation to k-lock Freedom In this section, we relate k-abortability to k-lock-freedom [5] (recall that when k ranges from 1 to n, k-lock-freedom ranges from lock-freedom to waitfreedom). Intuitively, an object O is k- lock-free if it ensures the following: (1) if at most k processes access O, then they all make progress, and (2) if more than k processes access O, then at least k of Algorithm 1. Implementing a k- lock-free object O of type T Shared Object: O : k-abortable object of type T 1: procedure invoke(op) 2: repeat 3: res O.invoke(op) 4: until res 5: return res them make progress. This is equivalent to the following requirement: a process can get stuck while accessing O only if at least k other processes make progress forever. More precisely: Definition 1. An object O is k-lock-free if it guarantees the following property: if a process invokes an operation on O and then takes an infinite number of steps without receiving a response from O, then at least k processes complete infinitely many operations on O. Algorithm 1 relates k-abortability to k-lock-freedom: for every type T, this algorithm implements O, ak-lock-free object of type T using O,ak-abortable object of type T. The algorithm is trivial: to invoke an operation op on O, a process invokes op on O until it doesn t abort; it then returns the value that was returned by O. So we have the following theorem, whose proof we defer to the full version of this paper. Theorem 2. In an n-process system, for all 1 k n and all type T :akabortable object of type T can implement a k-lock-free object of type T.

7 304 N. Ben-David et al. 4 k-abortable Universal Construction In this section, we present a k-abortable universal construction that takes O(k) steps per operation. As with many wait-free universal constructions, our construction assumes that the shared state of the implemented object can be stored in a single LL/VL/SC register, and therefore it takes constant time to copy. This assumption is reasonable for small objects; we discuss how to remove it for large objects in Sect. 6. At a high level, our construction is reminiscent of Individual Update, the adaptive universal construction presented in [1]. To initiate an operation, a process records the operation in a Records Array, which has one entry reserved for each process. It then tries to find an available slot in a separate Announcements Array, which determines the order in which operations will be helped. Finally, operations are executed through the use of a shared Core, in which all processes agree on the state of the object and the next operation to execute. However, our announcing procedure is significantly more involved than that of Individual Update [1]. The difference in the procedures stems from the difference in requirements. An operation on a k-abortable object must make sure that k operations by distinct processes succeed within its interval before it can abort. Adaptive implementations do not confront such a requirement. In our construction, the Announcements Array has only k slots. If a process succeeds in announcing its operation by securing a slot in the Announcements Array, that operation will not abort; it will get linearized as a successful operation, even if its initiating process is slow or has crashed. On the other hand, if a process fails to find an empty slot, its operation will eventually abort. However, before it does so, it needs to help the announced operations, to ensure that at least k of them get linearized during its interval. There are three main stages in the execution of an operation by a process: 1. The Recording Stage: The process records its intent to execute the operation in its slot in the Records Array. If this operation eventually gets helped by another process in the system, its response will be recorded in this slot as well. 2. The Announcement Stage: The process tries to announce its operation by securing a slot in the Announcements Array. This is done by sequentially checking whether each slot in the array is available. 3. The Helping Stage: Regardless of whether the process succeeded in announcing its operation, it attempts to help other operations. Only the operations in the Announcements Array are helped. There are two ways in which a process helps operations: (1) it executes the operation by calculating the outcome of applying it to the current state and then updating the object accordingly, and (2) it cleans up operations that have already been executed by relaying their response to their initiating process (by writing it in the appropriate slot in the Records Array).

8 k-abortable Objects: Progress Under High Contention Details of the Algorithm The detailed pseudocode is given in Algorithm 2. In the code, variables starting with g are global, and variables starting with l are local copies of global variables. Generally, processes that update global variables first get a local copy of the data they intend to change, make the changes locally, and then try to update the global variable accordingly. Each process keeps track of the number of operations it has executed, and assigns a unique ID (oid in the algorithm) for every operation it executes (line 2). The oid is an auxiliary variable; it is useful for referring to specific operations when discussing the algorithm s execution and the proof, but all appearances of oid in Algorithm 2 can be safely removed without affecting the correctness of the universal construction. The Records Array g rec contains n slots, one reserved for each process. Each slot contains 3 fields, all initially set to null. To initiate an operation, a process p fills its slot (g rec[p]) with information about the operation: its oid, its operation type optype, and a special value in the field res (line 17). If the operation is eventually applied, is replaced by the response value from the object. Otherwise, will remain in that slot for the duration of the operation s interval. When this operation terminates, it will return the value written in res at that time (line 50). After recording its intended operation, a process tries to announce it in the Announcements Array g ann which has only k slots. Each slot of g ann contains two fields, both initially null. Announcing is critical for the success of the operation: it will abort if and only if it doesn t get announced. The announcing stage involves iterating through g ann to try to find an available slot (lines 19 to 24). If an available slot is found, the process tries to store its pid and its operation s oid in it, and thereby claim the slot for its operation. A slot in g ann is considered available if one of two conditions hold (line 22): either (1) its pid value is null, i.e. no process has claimed it, or (2) the process which claimed it has already finished its operation. This second condition is checked by reading the res field of the operation record in g rec. Ifres is not, then the operation has already been executed, and no longer needs to occupy the announcement slot. Note that a process will never hold on to a slot in g ann and use it for subsequent operations: once its current operation is successfully applied, if no other process claims the slot (line 45), the process will unannounce its own operation by resetting the fields of the slot back to null (line 46). When trying to announce, a process p checks each slot in g ann twice before it moves on to the next (line 20). Intuitively, this is done to ensure that if p does not manage to announce in slot i, then that slot is truly occupied by another operation that needs help. The problem with a single check is that p might fail its SC because of an unannouncing process, which means that the slot could actually be available throughout the entire execution interval of p s operation. Checking each slot twice eliminates this possibility, and this is crucial for correctness of the algorithm. Specifically, it is necessary for proving that within the execution interval of each operation that aborts, k operations by distinct processes succeed.

9 306 N. Ben-David et al. Algorithm 2. k-abortable Universal Construction for Objects of Type T Shared Objects: g rec[1..n]: Records Array. LL/SCs containing {oid: int, optype: operation type, res: a response}; all set to null. g ann[1..k]: Announcements Array. LL/VL/SCs containing {oid: int,pid: int}; allsettonull. g core: LL/VL/SC containing {state: a state, aid: int, oid: int, pid: int, res: a response}; set to {s 0, 1, null, null, null}. Code performed by process p: 1: procedure universal(my optype) 2: my Oid my Oid +1 Auxiliary persistent variable denoting the operation s ID 3: record(my optype) To start operation, record it in the Records Array 4: my Aid announce() Try to announce the operation 5: if my Aid nullthen Successfully announced; will not abort 6: repeat 7: my res g rec[p].ll().res Check if my operation is done 8: help() 9: until my res 10: unannounce(my Aid) Clear my slot in the Announcements Array 11: else Failed to announce. Will abort after helping 12: loop k +2times 13: help() Help linearize at least k operations 14: return unrecord() Clear record of operation before terminating 15: procedure record(my optype) Record your intention to execute the operation. 16: g rec[p].ll() 17: g rec[p].sc((my Oid, my optype, )) This SC always succeeds. 18: function announce() 19: for j :1...k do Go over array sequentially, trying to announce in each slot in turn 20: loop 2 times Trying each slot twice ensures that failure is justified 21: temp Pid g ann[j].ll().pid 22: if temp Pid =nullor g rec[temp Pid].LL().res then If slot is free 23: if g ann[j].sc((my Oid,p)) then Try to announce there 24: return j If successful, return the index of the slot 25: return null If the entire array was occupied, return with failure 26: procedure help() 27: l core g core.ll() Create a local copy of the Core 28: if l core.pid nullthen Clean up the previous operation (if it has not yet been cleaned). 29: l rec g rec[l core.pid].ll() Check if the response should be relayed to the Record 30: if g core.vl() then return Ensure that the local Core is still up to date 31: if l rec.res = then The response entry is blank, so the operation needs help 32: l rec.res l core.res Copy the response from the Core to the process s record 33: g rec[l core.pid].sc(l rec) This is the helped operation s linearization point 34: l core.aid (l core.aid mod k) + 1 Determine which announcement to help next 35: (l core.oid, l core.pid) (null, null) 36: l ann g ann[l core.aid].ll() Find the operation to help 37: if l ann.pid nullthen 38: l rec g rec[l ann.pid].ll() Check whether the operation needs help 39: if l rec.res = then 40: if g ann[l core.aid].vl() then Ensure that operation is still announced. 41: (l core.oid, l core.pid) (l ann.oid, l ann.pid) 42: (l core.state, l core.res) apply T (l core.state, l rec.optype) Execute locally 43: g core.sc(l core) Attempt to replace the Core by its local copy. 44: procedure unannounce(my Aid) Remove yourself from the Announcements Array. 45: if g ann[my Aid].LL().pid = p then 46: g ann[my Aid].SC((null, null)) 47: function unrecord() Read the response and clear your Record. 48: my res g rec[p].ll().res 49: g rec[p].sc((null, null, null)) This SC always succeeds. 50: return my res

10 k-abortable Objects: Progress Under High Contention 307 Whether a process succeeds or fails to announce its operation, it proceeds to help some announced operations using the help procedure. The execution of help begins by performing an LL on g core to get a local copy l core (line 27). The Core holds the current state of the object (state), and may also hold information about the operation that was most recently executed. In that case, oid and pid describe the operation and its process, aid is the index at which this operation was announced in g ann,andres is the response returned by the object when the operation was applied to it. We say that the operation described by the fields in g core is the scheduled operation. The help procedure proceeds in two stages. First, if there is a scheduled operation op (line 28), the process helps to copy the response in l core to op s record if it still has in res (line 31). Second, l core.aid is moved to the next slot of g ann, and if the slot is not available, the process helps the announced operation become scheduled. To do so, the helping process applies the operation to l core.state to determine the next state and response (line 42). Note that apply T corresponds to the state transition relation δ of type T. At the end of the help procedure, the process attempts to finalize all of the changes it has performed on its local copy l core by copying its contents into g core via an SC (line 43). A process that successfully announces its operation repeats the help procedure until it finds its response in its slot of the Records Array; this will occur after at most k + 3 executions of help. A process that fails to announce its operation executes the help procedure k + 2 times. Once a process p receives the response for its operation op, p does some cleanup before op terminates. Specifically, it executes the help procedure one more time (line 8), and calls unannounce (line 10) and unrecord (line 14). This ensures that this operation will not interfere with its subsequent ones. 4.2 Correctness Proof Sketch Theorem 3. Algorithm 2 implements a k-abortable object of type T. To show this, we need to prove the following. For every history H of O, there is a completion H and a linearization L of H such that: (1) the linearization L of H conforms to T (2) for each operation op that aborts in H, there are k operations from distinct processes that do not abort in H and whose linearization points in L is within the execution interval of op in H. Intuitively, each operation whose record gets a response is linearized at that time (line 33), while aborting operations are linearized when they terminate. We leave the construction of H and L to the full version of the paper. Lemma 4. The linearization L of history H conforms to type T. In order to show that L conforms to T, we first need to show that aborted operations don t change the state of the object. Roughly speaking, this is because an operation that aborts does so because it was never announced, and therefore no process applies it. Thus, it does not have any effect on the object. The actual

11 308 N. Ben-David et al. proof is more intricate, since we need to ensure that the help procedure indeed only helps operations that are announced, and doesn t accidentally follow outdated pointers to find and help operations that should not be helped. Since T is the abortable counterpart of type T, we also need to show that, aside from aborts, the object behaves as if it is of type T. Intuitively, g core holds the state of O, and is only modified when an operation is stored in the Core. Whenever that happens, line 42 applies the operation according to the state transition relation of type T. Lemma 5. For each operation op that aborts in H, there are k operations from distinct processes that do not abort in H and whose linearization points in L are within the execution interval of op in H. To show Lemma 5, we begin with the following claim, whose proof we defer to the full version of the paper. We say that an operation is open at time t if it has been invoked but not linearized by time t. Claim 6. An attempt by an operation op to announce at slot i of the Announcements Array only fails if at some time t during the attempt, there is an open operation in slot i. Claim 7. Let t op s denote the starting time of an operation op. If op fails to announce in slot i at time t i then at some time t in [t op s,t i ], there are i other open operations, each announced in some slot 1...i before time t i. Proof. The proof is by induction on i. Ifop fails to announce in slot 1 at time t 1, Claim 6 asserts that at some time t during op s attempt to announce in slot 1, there is an open operation in slot 1. Assume that the claim holds for slot i 1. Suppose that op fails to announce in slot i at time t i. Then by Claim 6, there is an open operation op announced at slot i at time t i <t i. Since operations have to go through the announce array sequentially and try each slot, both op and op must have tried and failed to announce in slot i 1 at time t i 1 <t i and t i 1 <t i <t i, respectively, before attempting to announce in slot i. So, by the induction hypothesis (because op and op failed to announce in slot i 1), there are times t [t op s,t i 1 ]and t [t op s,t i 1 ]andsetss t and S t of i 1 operations each that are open at times t and t, and are announced in some slot 1...i 1 before time t i 1 and t i 1. Let t max = max{t, t } and S tmax be the corresponding set of i 1 open operations. Since neither op nor op were announced in any slot 1...i 1, neither of them belong to S tmax. Furthermore, both op and op are open at t max. Since t [t op s,t i 1 ]andt [t op s,t i 1 ]andt i 1 <t i and t i 1 <t i,wehavet op s <t<t i and t op s <t <t i ;thust op s <t max <t i.sos tmax {op } is a set of i operations, all of which are open at time t op s <t max <t i, and which were all announced in some slot 1...i before time t i. Therefore, the claim holds for slot i. Suppose an operation op of a process p aborts. Clearly op failed to announce its operation. By Claim 7 (with i = k), there is a time within its execution interval during which there are k other open operations. Since each process can

12 k-abortable Objects: Progress Under High Contention 309 only execute one operation at a time, these must be operations by k different processes. In addition, we know that all of these operations get announced before op fails to announce. To complete the proof of Lemma 5, it remains to show that these k operations are linearized before op terminates. To see this, first note that a process that fails to announce its operation executes the help procedure k + 2 times. The following claim (whose proof we defer to the full version of the paper) immediately implies Lemma 5: Claim 8. All operations announced before p starts executing the help procedure are linearized by the time p finishes executing the help procedure k +2 times. 4.3 Running Time Theorem 9. Each operation terminates within O(k) steps. Proof. The record, unrecord, help and unannounce procedures take constant time. The announce procedure contains one loop, which gets executed at most 2k times. Among these procedures, help is the only procedure that is called more than once per operation. If a process p fails to announce its operation, it only executes the help procedure k + 2 times. Otherwise, it executes the help procedure until its record has been given a response. Recall that an announced operation is linearized when it receives a response. Claim 8 asserts that after p executes the help procedure k + 2 times, its operation must be linearized, so p will find its response in the Records Array during the next execution. 5 Lower Bound In this section, we show a Ω(log k)-steps lower bound on wait-free universal constructions of k-abortable objects shared by n processes. This result is a consequence of Jayanti s lower bound in [11]. Theorem 10. Consider a shared-memory system S that supports only LL, SC, VL (i.e., validate), move, and swap operations. Given any wait-free implementation of a k-abortable fetch&increment shared by n k processes, some operation requires Ω(log k) steps. Proof [Sketch]. Suppose, for contradiction, that there is a wait-free implementation I of a k-abortable fetch&increment shared by n k processes such that all operations take o(log k) steps in system S. Observe that when at most k processes access the object implemented by I, no operation can abort, so I implements an ordinary, non-abortable fetch&increment. Thus, I is also a waitfree implementation of a fetch&increment shared by k processes such that all operations take o(log k) steps in system S. By Theorem 6.2 in [11], however, for every wait-free implementation of a fetch&increment shared by k processes in system S, some operation requires Ω(log k) steps a contradiction. Corollary 11. For every wait-free universal construction of k-abortable objects shared by n processes in system S, some operation requires Ω(log k) steps.

13 310 N. Ben-David et al. 6 Concluding Remarks In Sect. 4, we gave a universal construction of k-abortable objects in which every operation takes at most O(k)-steps. As we mentioned before, our construction has similarities with an adaptive wait-free universal construction called Individual Update given by Afek et al. in [1]: this construction takes O(l) steps per operation, where l is the number of processes that access the object concurrently. Under high contention, however, operations may take O(n) steps with the adaptive construction, whereas operations never take more than O(k) steps with our construction, at the cost of sometimes aborting. Another difference between our construction and the adaptive one is how slow or crashed processes affect the performance of other processes. With the adaptive construction, a slow process can in turn slow down other processes: l counts all processes accessing the object. For example, if most of the n processes slow down or crash in the middle of an operation, all subsequent operations of the remaining processes may take O(n) steps. 7 In contrast, a process p that slows down or crashes while accessing a k- abortable object does not degrade the performance of other processes; as long as p remains in the object, p (together with k 1 other processes) can cause each process to abort at most once. Note that this property is not a special feature of our universal construction: it is a property inherent in the definition of k-abortability; the k operations that cause an operation op to abort are linearized during op s execution, so they cannot cause operations that start after op to abort. Adaptivity and k-abortability are orthogonal concepts: it may be possible to combine their benefits into adaptive k-abortable objects, but doing so remains an open problem. As with many wait-free universal constructions, including the well-known one given by Herlihy in [8], our construction assumes that the shared state of the implemented object can be stored in a single base object. While this assumption may be reasonable for small objects, it is not tenable for objects with unbounded state, such as queues and stacks. One method to support such data structures using base objects of small size, called Agree on Changes, was proposed by Afek et al. in [1]. We can apply the same method to our universal construction so that: (a) it uses LL/VL/SC objects of bounded size, and (b) every operation on a k-abortable object O takes O(kf(s))-steps, where f(s) is the sequential complexity of O, i.e., f(s) is the maximum number of steps required by a sequential algorithm to apply any operation on O when O has size s. For queues and stacks, f(s) = 1, and therefore we can implement k-abortable queues or stacks that take O(k) steps per operation, while using only bounded-size LL/VL/SC objects. In contrast, the best wait-free implementation of a queue that we are aware of takes Θ(n) steps per operation [12]. For some popular data structures, there may be k-abortable implementations that are simpler and more efficient than those given by our universal construction 7 This is not obvious, but it is possible to construct such runs of the adaptive algorithm in [1].

14 k-abortable Objects: Progress Under High Contention 311 of k-abortable objects. For small values of k, such implementations may prove to be attractive alternatives to lock-free data structures [4, 13]. Our Ω(log k) lower bound for k-abortable universal constructions was derived from Jayanti s Ω(log n) lower bound for wait-free universal constructions [11] in shared-memory systems that support only LL, VL, SC, move, and swap operations. Under the impractical assumption that a LL/VL/SC object can store n operations, Jayanti observed that his lower bound is tight: there is a wait-free universal construction that takes O(log n) steps per operation. In fact, Fatourou and Kallimanis [6] proved that, with LL/VL/SC and Fetch&Add objects of size Θ(n), one can beat the Ω(log n) lower bound: they present a wait-free universal construction that uses such objects and takes only O(1) steps per operation. They note, however, that this construction is not practical since it employs a large Fetch&Add object, and give a practical version of it that uses only objects of reasonable size but takes Ω(n) steps per operation. The time complexity of universal constructions for both wait-free and k-abortable objects using only objects of reasonable size is an open question. References 1. Afek, Y., Dauber, D., Touitou, D.: Wait-free made fast. In: Proceedings of the Twenty-Seventh Annual ACM Symposium on Theory of Computing, pp ACM (1995) 2. Aguilera, M.K., Frolund, S., Hadzilacos, V., Horn, S.L., Toueg, S.: Abortable and query-abortable objects and their efficient implementation. In: Proceedings of the Twenty-Sixth Annual ACM Symposium on Principles of Distributed Computing, pp ACM (2007) 3. Attiya, H., Guerraoui, R., Kouznetsov, P.: Computing with reads and writes in the absence of step contention. In: Fraigniaud, P. (ed.) DISC LNCS, vol. 3724, pp Springer, Heidelberg (2005) 4. Brown, T., Ellen, F., Ruppert, E.: A general technique for non-blocking trees. In: Proceedings of the 19th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming, pp ACM (2014) 5. Bushkov, V., Guerraoui, R.: Safety-liveness exclusion in distributed computing. In: Proceedings of the Twenty Fourth Annual ACM Symposium on Principles of Distributed Computing. ACM (2015) 6. Fatourou, P., Kallimanis, N.D.: Highly-efficient wait-free synchronization. Theor. Comput. Syst. 55(3), (2014) 7. Hadzilacos, V., Toueg, S.: On deterministic abortable objects. In: Proceedings of the 2013 ACM Symposium on Principles of Distributed Computing, pp ACM (2013) 8. Herlihy, M.: Wait-free synchronization. ACM Trans. Program. Lang. Syst. (TOPLAS) 13(1), (1991) 9. Herlihy, M., Luchangco, V., Moir, M.: Obstruction-free synchronization: Doubleended queues as an example. In: 23rd International Conference on Distributed Computing Systems, Proceedings, pp IEEE (2003) 10. Herlihy, M.P., Wing, J.M.: Linearizability: a correctness condition for concurrent objects. ACM Trans. Program. Lang. Syst. (TOPLAS) 12(13), (1990)

15 312 N. Ben-David et al. 11. Jayanti, P.: A time complexity lower bound for randomized implementations of some shared objects. In: Proceedings of the Seventeenth Annual ACM Symposium on Principles of Distributed Computing, pp ACM (1998) 12. Kogan, A., Petrank, E.: Wait-free queues with multiple enqueuers and dequeuers. ACM SIGPLAN Not. 46, (2011). ACM 13. Michael, M.M., Scott, M.L.: Simple, fast, and practical non-blocking and blocking concurrent queue algorithms. In: Proceedings of the Fifteenth Annual ACM Symposium on Principles of Distributed Computing, pp ACM (1996) 14. Taubenfeld, G.: Contention-sensitive data structures and algorithms. In: Keidar, I. (ed.) DISC LNCS, vol. 5805, pp Springer, Heidelberg (2009)