NonBlocking StealHalf Work Queues


 Arline Stella Ryan
 1 years ago
 Views:
Transcription
1 NonBlocking StealHalf Work Queues Danny Hendler TelAviv University Nir Shavit TelAviv University Abstract The nonblocking workstealing algorithm of Arora et al. has been gaining popularity as the multiprocessor load balancing technology of choice in both Industry and Academia. At its core is an ingenious scheme for stealing a single item in a nonblocking manner from an array based deque. In recent years, several researchers have argued that stealing more than a single item at a time allows for increased stability, greater overall balance, and improved performance. This paper presents StealHalf, a new generalization of the Arora et al. algorithm, that allows processes, instead of stealing one, to steal up to half of the items in a given queue at a time. The new algorithm preserves the key properties of the Arora et al. algorithm: it is nonblocking, and it minimizes the number of CAS operations that the local process needs to perform. We provide analysis that proves that the new algorithm provides better load distribution: the expected load of any process throughout the execution is less than a constant away from the overall system average. 1 Introduction The workstealing algorithm of Arora et al. [2] has been gaining popularity as the multiprocessor loadbalancing technology of choice in both Industry and Academia [1, 2, 5, 7]. The scheme allows each process to maintain a local work queue, and steal an item from others if its queue becomes empty. At its core is an ingenious scheme for stealing an individual item in a nonblocking manner from a bounded size queue, minimizing the need for costly CAS (CompareandSwap) synchronization operations when fetching items locally. Though stealing one item has been shown sufficient to optimize computation along the "critical path" to within a constant factor [2, 4], several authors have argued that the scheme can be improved by allowing multiple items to be stolen at a time [3, 8, 9, 12]. Unfortunately, the only implementation algorithm for stealing multiple items at a time, This work was supported in part by a grant from Sun Microsysterns. Contact author: Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the fifll citation on the first page. To copy otherwise, or repubfish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. PODC 2002, July 2124, 2002, Monterey, California, USA. Copyright 2002 ACM /02/ $5.00. due to Rudolph et al. [12], requires the local process owning the queue to use a strong synchronization operation (CAS or some other form of mutual exclusion) for every push or pop. Since the local process' operations are far more frequent, this makes the Rudolph et al. algorithm significantly less effective than that of Arora et al. This state of affairs leaves open the question of designing an algorithm that, like Arora et al., does not use costly synchronization operations in every step, yet allows stealing multiple items at a time, thus achieving the stability, balance, and improved performance of algorithms like Rudolph et al. 1.1 The New Algorithm This paper presents a new workstealing algorithm, Steal Half, a generalization of the Arora et al. algorithm, that allows processes to steal up to half of the items in a given queue at a time. Our StealHalf algorithm preserves the key properties of the Arora et al. algorithm: it is nonblocking and it minimizes the number of CAS operations that the local process needs to perform. We provide a performance analysis showing that our algorithm improves on Arora et al. by providing an overall system balance similar to the Rudolph et al. scheme: the expected load of any process throughout the execution is less than a constant away from the overall system average. In our algorithm, as in the Arora et al. algorithm, each process has a local work queue. This queue is actually a deque, allowing the local process to push and pop items from the bottom, while remote processes steal items from the top. The Arora et al. algorithm is based on a scheme that allows the local process, as long as there is more than one item in the deque, to modify the bottom counter without a CAS operation. Only when the top and bottom are a distance of 1 or less apart, so that processes potentially overlap on the single item that remains in the deque, does the process need to use a CAS operation to perform consensus. This consensus is necessary because the inherent uncertainty [6] regarding a single read or write operation to the top and bottom counters can affect whether the last item to be stolen is still there or not. This yields an algorithm where for any monotonic sequence of k pushes or k pops, 1 the number of 1A monotonic sequence is a sequence of local operations that monotonically either increases or decreases the bottom counter. We define the synchronization complexity in terms of monotonic sequences since one cannot make claims in nonmonotonic situations where the execution pattern of the underlying application causes thrashing back and forth on a single location. 280
2 CAS operations is O(1). In order to steal more than one item at a time, say half of the number of items in a deque, one must overcome a much greater uncertainty. Since a stealing process might remove up to half of the items, there are now many values of the bottom counter, say, up to half of the difference between top and bottom, for which there is a potential overlap. Thus, eliminating the uncertainty regarding reading and writing the counter requires consensus to be performed for half the items in the deque, an unacceptable solution from a performance point of view, since it would yield an algorithm with O(k) synchronization complexity. The key to our new algorithm is the observation that one can limit the uncertainty so that the local process needs to perform a consensus operation (use a CAS), only when the number of remaining items in the deque (as indicated by the difference between top and bottom), is a power of two! The scheme works so that as the distance between the bottom and top counters changes, it checks and possibly updates a special halfpoint counter. The uncertainty regarding a single read or write exists just as in the Arora et al. algorithm, only now it happens with respect to this counter. What we are able to show is that missing the counter update can only affect locations beyond the next poweroftwo at any given point. For any monotonic sequence of k pushes or k pops, our algorithm uses only O(logk) CAS operations, slightly worse than Arora et al., but exponentially better than the O(k) of the Rudolph et al. scheme. Like the Arora et al. scheme, our StealHalf algorithm is nonblocking: the slowdown of any process cannot prevent the progress of any other, allowing the system as a whole to make progress, independently of process speeds. Like Arora et al., the nonblocking property in our algorithm is not intended to guarantee faulttolerance: the failure of a process can cause loss of items. Arora et al. claim that their empirical testing on various benchmarks shows that the nonblocking property contributes to performance of work stealing, especially in multiprogrammed systems [2]. In our algorithm, the price for unsuccessful steal operations is a redundant copying of multiple itempointers, whereas in the Arora algorithm only a single pointer is copied redundantly. However in our algorithm, successful stems transfer multiple items at the cost of a single CAS, whereas in the Arora et al. scheme a CAS is necessary for each stolen item. 1.2 Performance Analysis Mitzenmacher [9] uses his differential equations approach [10] to analyze the behavior of work stealing algorithms in a dynamic setting, showing that in various situations stealing more than one item improves performance. Berenbrink et al. [3] have used a markov model to argue that a system that steals only one item at a time can slip into an instable state from which it cannot recover, allowing the number of items to grow indefinitely. This implies that no matter how much buffer space is allocated, at some point the system may overflow. Treating such overflow situations requires the use of costly overflow mechanisms [5]. Berenbrink et al. [3] further show that an Aroralike scheme that allows stealing, say, half of the items, will prevent that system from slipping into such an instable state. Rudolph et. al [12], and later Luling and Monien [8], prove that in a load balancing scheme that repeatedly balances the work evenly among random pairs of local work queues, the expected load of each process will vary only by a constant factor from the load of any other process and that the overall variance is small. The algorithm we present is generic, in the sense that one can change the steal initiation policy to implement a variety of schemes including those of [2, 3, 12]. We choose to analyze its behavior in detail under a steaiattempt policy similar to [12]: ever so often, every process p performs the following operation, which we call balancing initiation: p flips a biased coin to decide if it should attempt to balance its workload by stealing multiple items, where the probability of attempting is inversely proportional to its load. If the decision is to balance, then p randomly selects another process and attempts to balance load with it. Our main Theorem states that our algorithm maintains properties similar to those of Rudulph et al. We provide it here since the proof provided by Rudolph et al. turns out to be incomplete, and also because there are significant differences between the algorithms. As an example, the Rudolph et al. algorithm is symmetric: a process can both stealitemsfrom and insertitemsto the deque of another process. In our algorithm, however, a process can only steal items. Assume A~ is a time period where no deque grows or shrinks by more than u items (through pushing or popping). Let Lp,t denote the number of items in process p's deque at time t; also, let At denote the averageload at time t. Then if all processes perform balancing initiation every A~ time, there exists a constant c~, not depending on the number of processes or the application, such that: 'v'p,t : E[Lp,t] < oluat The existence of such Au is a natural assumption in most systems, and can be easily maintained with slight protocol modifications in others. In contrast, it can easily be shown, that if one steals a single item at a time as in the Arora et al. scheme, even if stealattempts are performed every A1, there are scenarios in which the system becomes instable. In summary, we provide the first algorithm for stealing multiple items using a single CAS operation, without requiring a CAS for every item pushed or popped locally. An outline of the algorithm is presented in Section 2; the analysis is presented in Section 3; finally, correctness claims are presented at Section 4. 2 The StealHalf algorithm As noted earlier, the key issue in designing an algorithm for stealing multiple items is the need to minimize the use of strong synchronization operations both when performing local operations and when stealing multiple items. A first attempt at an algorithm might be to simply let a process steal a range of items by repeatedly performing the original code of stealing a single item for every item in the group. This would make the algorithm a stealmany algorithm 2 but at a very high cost: to steal k items, the thief would have to perform k synchronization operations. The algorithm presented here, utilizes an extended deque data structure, a variant of the deque of [2] depicted in Figure 1, to achieve synchronization at a low cost. The extended deque differs from the deque of [2] in two ways: (1) it is implemented as a cyclic array, and (2) it contains a memberstructure, called steairange, which defines the range of items that can be stolen atomically by a thiefprocess. 2Obviously with this technique the itemsgroup is not stolen atomically. 281
3 Extended Deque deque stealrange 1 tag J *. ' up to 2^i items top I can be stolen atomically last j.w" * I' : ' there are at least 2"i bot * items outside the stealrange : the bottom of the deque is somewhere in this group of 2^0+1) items Figure 1: The extended deque The algorithm allows stealing about half the items of the victim in a single synchronization operation. It does this by always maintaining the invariant that the number of items in every process p's steairange is approximately half the number of total items in p's deque. Process p's steairange is updated by any process that succeeds in stealing items from p's deque, and also by p itself. To keep the number of synchronization operation performed by a local process p as low as possible, p updates its steairange when pushing or popping an item to/from its deque, only if at least one of the following events occur: The number of items in p's deque crosses a 2 i boundary, for some i E N; A successfulsteal operation from p's deque has occurred since the last time p modified its own steal Range. 2.1 Data structures Each process owns an extended deque structure, which it shares with all other processes. In this structure: deq is an array that stores pointers or handles to items, which are generated and consumed dynamically. It has DEQ_SIZE entries. The range of occupied entries in deq includes all the entries in the range: [top... bot)deq_size 3. As noted, it is implemented as a cyclic array. The steairange memberstructure extends the age structure from [2]. It contains the following fields: tag  as in [2], a time stamp on the updating of the steairange structure. A tag is required in order to overcome the ABA problem inherent to the CAS primitive. 4 As in [2], the bounded tag algorithm of [11] can be used. top  as in [2], the pointer to the topmost item in the deque. ~ 3[a  "  b)m denotes the halfopen entriesrange, from entry a upto entry b (including a but not b), modulus m. 4Assume a process p reads a value A from location m, and then performs a successful CAS operation, which modifies the contents of m. Process p's CAS should ideally succeed only if the contents of m was not modified since it read value A. The problem is, that if other processes modified m's value to value B and then back again to A in the interim  the CAS operation still succeeds. To overcome this problem, a tag field is added to the structure. 5Note, that because the extended deque is cyclic, the item pointed to by top is not necessarily the item stored at the topmost dequeentry. The item pointed at by top is invariably the first item of the stealrange. steailast  points to the last item to be stolen. The items that would be stolen next (unless the streal Range structure would be modified by the local process before the next steal) are in the range [top... steailast]d~q_~lze 6. The steallast variable can assume the special value null, which indicates there are no items to steal. The stealrange structure is modified via CAS operations. The bot field points to the entry following the last entry containing an item. Since the extended deque is cyclic, bot may be smaller than top. If bot and top are equal, the extended deque is empty. In addition to the shared extendeddeque structure, each process has a static and local structure, called prevsteairange, of the same type as steairange. It is used by the local process to determine whether a steal has occurred since the last time the process modified the stealrange. 2.2 Highlevel extendeddeque methods description We specify the algorithm in a generic manner, that allows "pluggingin", in a modular way, components that allow flexibility in regard to the conditions/policy that control when a stealattempt is initiated Balancing initiation code The code that appears in figure 2 should be performed by every process periodically, throughout the computation. IF (shouldbalanceo) Process *victim=randomprocesso; TryToSteal(victim); Figure 2: stealinitiation code The shouldbalance method determines the policy regarding when to initiate a steal attempt 7. Many policies are conceivable, a few of which are: Try to steal only when the local deque is empty: this is the scheme implemented by Arora et al. [2], and we call it: stealonempty. Try to steal probabilistically, with the probability decreasing as the number of items in the deque increases: this scheme was suggested by Rudolph et al. [12], and we call it probabilistie balancing s Try to steal whenever the number of items in the deque increases/decreases by a constant factor from the last time a stealattempt was performed: this is the policy suggested in [3]. 6[a b]m denotes the closed arrayrange, from entry a upto entry b (including both a and b), modulus m. 7This can be implemented as inlined code rather than as a method, if this code should be performed very often. SThe scheme, as described, is always probabilistic in the sense that the victim process is selected at random. The probabilistic balancing scheme adds yet another probabilistic factor. 282
4 Stealinitiation policies can vary significantly with respect to the extent they make the system balanced, but obviously none can guarantee that the system is balanced, if balancing is not attempted frequently enough. Consequently, we have to make some reasonable assumptions regarding the frequency at which the stealinitiation code is performed. Let Au be a timeperiod small enough, such that it is guaranteed that no process p changes its load by more than u items during that period, by generating/consuming items (thefts notwithstanding). In the analysis we prove, that if the probabilistie balancing policy is employed, and the stealinitiation code is performed once every Au period, then the expected number of dequeitems of any process p at any time during the execution is no more than o~ times the total average, where a~ is a constant that does not depend on the number of processes or the dynamic pattern of item generation/consumption 9. Not every stealinitiation policy can guarantee this property, though. It can easily be shown, that under the stealonempty policy, where only a single item is stolen at a time, a system can grow unbalanced beyond any bound, even if the stealinitiation code is performed every A1 time period! The balancing initiation code can be performed periodically by the system or by an application, or it can be implemented as a signalhandler pushbottom code A highlevel pseudocode of pushbottom is shown in Figure 3. RETIJRN_CODE pushbottom(item *e) { IF deq is full return DEQ_FULL deq[bot] = e increment hot in a cyclic manner IF (deq length now equals 2"i for some i) Try to CASupdate the stealrange to contain max(1,2"(i1)) items ELSE IF (stealrange!= prevstealrange) Try to CASupdate the stealrange to contain max(1,2"i) items, where the current length of the deque is in the range [ 2~(i+I),2~(i+2) ) IF CAS was performed successfully prevstealrange = stealrange Figure 3: pushbottom pseudo code The pushbottom operation is performed by the local process p, whenever it needs to insert a new item into its local deque. If the deque is not full, the new item is placed in the entry pointed at by bot, and bot is incremented in a cyclic manner. However, if following the insertion of the new item the length of p's deque becomes 2 i for some i > 0, then p tries to CASupdate its steairange to contain the topmost 2 i1 items 1. This is to make sure the length of the steal Range is not much less than half the total number of items in the deque 11 Process p has to update the steairange even if the dequelength is not a power of 2, if another process has succeeded 9Obviously, A~ itself does depend on this pattern. 1 or 1, if i=0. 1aWe actually prove in the full paper that for any process p, at any time, the length of p's stealrange is at least ~'th of the length of p's deque. Before pushbottom0 bot de( e ste~ o After pushbottomo dequ(!i' 4, 5, 6' y o bot. ~ 1514 Figure 4: The extended deque before and after a pushbottom. Right after pushbottom inserts a new item into the deque, it checks whether the deque length reaches a powerof2 boundary (in the above Figure, the 16'th item was added), in which case steairange is expanded to contain the first half of the dequeelements. in stealing items from p since the last time p updated its stealrange. Process p can identify this by comparing the current value of its steairange with the last value it wrote to it  which is stored at its local prevstealrange. If the values differ, p tries to set the length of its steairange (by a CAS) to be max(l, 2/), where 2 TM _< len(deq) < 2/+2. If p performed a successful CAS, prevstealrange is updated with the value it wrote. Figure 4 depicts the state of an extended deque before and after the 16'th item is pushed into it. Since subsequent to the push the deque contains a powerof2 number of items, pushbottom tries (and in this case succeeds) to expand stealrange. It is easily seen (and is proven in our analysis) that immediately after every successful CAS operation performed by pushbottom, assuming that the pushed item is not the first item in the deque 12, the following holds: 2 len(stealrange) < len(deq) < 4 len(steairange) popbottom code A highlevel pseudocode of popbottom is presented in Figure 5. The popbottom operation is performed by the local process p whenever it needs to consume another dequeitem. Section 1: In section 1 a process performs some prechecks to make sure the method may proceed. It first checks whether the deque is empty, in which case the method returns null; it next checks whether the length of the deque is 2 i for some i _> 0. If this is indeed the case, then the method tries to CASupdate its steal Range to contain the topmost 2 i2 items 13. This is done in order to maintain the invariant that the length of stealrange neve~ exceeds half the total number of 12If the pushed item is the first item of the deque, then the lengths of both the deque and the steairanye right after the CAS equal 1. lsor 1, if i <
5 Item *popbottomo { Section 1 IF deq is empty return null IF (deq length now equals 2"i for some i) Try to CASupdate the stealrange to contain max(l,2^(i2)) items ELSE IF (stealrange!= prevstealrange) Try to CASupdate the stealrange to contain max(l,2*i) items, where the current length of the deque is in the range (2^(i+1)... 2~(i+2) ] Section 2 IF CAS was performed successfully prevstealrange = stealrange ELSE IF a CAS was attempted but failed return ABORT; Before popbottom0 d~ue stealrange 4 o 4 vf.* 2: 1 ~=t / * 3, [tools * 4, I'"t 5, Ilasfl~ * 6, t. J ~ * 7 1 bot * 8 * 9 * l~ * 11 * 12 * 13 * 14 * After popbottomo deque s t e ~ a J bot Decrement bot in a cyclic manner Item *e = deq[bot] oldstealrange = this>stealrange IF oldstealrange does not contain bot return e (no need to synchronize) ELSE IF oldstealrange is empty { bot=o (the last item  e  was already stolen by another process) return null } ELSE { Try to CASupdate the stealrange to be empty IF succeeded return e (e was not stolen so far) ELSE return null (the last item  e  was already stolen by another process) } } Figure 5: popbottom pseudo code items in the deque, unless there's a single item in the deque. As in pushbottom, p has to CASupdate the stealrange even if the dequelength is not a power of 2, if another process has succeeded in stealing items from p since the last time p updated its stealrange. Process p can identify this by comparing the current value of its stealrange with the last value it wrote to it  which is stored at prevsteairange. If the values differ, p tries to set the length of its stealrange to be max(1,2i), where T +1 < len(deq) _< T +2. If popbottom performed a successful CAS, it updates prevsteairange with the value it wrote. If however a CAS was attempted and failed, popbottom returns a special value ABORT, indicating this situation. Note, that this can only happen if a successful steal has occurred concurrently with the method's execution. 14. Section 2: Section 2 is very similar to its stealone [2] counterpart: it pops the bottomitem e off the deque, and then reads steairange. If this read does not include e, then the method returns e and exits, as no 14An alternative implementation is to retry again and again in a loop, until the method succeeds in updating stealrange. Figure 6: The extended deque before and after a popbottom. Just before popbottom pops the bottommost item from the deque, it checks whether the deque length is exactly at a powerof2 boundary (in the above Figure, the 16'th item is about to be popped), in which case stealrange is being shrank to contain the first quarter of the dequeelements other process may have stolen e; otherwise, there are 2 possibilities:  stealrange is empty  e was stolen by another process during the method's execution. The method returns null.  e is the oneandonly item in the deque, in which case the method tries to CASupdate stealrange with an empty range value. If it succeeds  it returns e as its result, otherwise it returns null. Figure 6 depicts the state of an extended deque before and after the 16'th item is popped off it. Since prior to the pop the deque contains a powerof2 number of items, popbottom tries to shrink stealrange (and in this case succeeds). It is easily seen (and is proven in our analysis) that immediately after every successful CAS operation performed by popbottom the following inequalities hold 15 2 * len(steairange) _< len(deq) _< 4 * len(steairange) trytosteal code The try ToSteal method is the method that actually attempts to perform a steal. It is called by a local process p, after the stealinitiation policy has determined that a stealattempt should be made and a victim process has been selected. The pseudocode of trytosteal is shown in Figure 7. The method receives 2 parameters: d  a pointer to the victim process' extendeddeque, and plen  the number of items in p's deque, and returns the number of items actually stolen. It first reads d.stealrange and computes its length, 15The below inequalities hold, unless the number of items in the deque after the pop is 0 or 1. If the pop empties the deque, then the lengths of both the deque and the steal_range after the operation are 0; if a single item is left in the deque after the pop, the lengths are both
6 based on which the method can determine whether it is certain that the victim has more items than p has; if this is not the case  the method returns 0 without stealing any item. Otherwise, about half of the guaranteed difference between the sizes of the 2 deques is copied to p's deque, and then p tries to CASupdate the victim's stealrange. The length of the new steairange is set to be max(l, 2i2), where the length of the victim's deque before the theft was in the range: [2 i... 2i+1). As we prove in our analysis, this guarantees that the new steairange has length that is at most half, and at least one eighth the remaining number of items. If the CAS fails, the stealattempt has failed also, and the method returns 0; otherwise  the stealattempt has succeeded, and the method proceeds to update p's bot and steal Range to reflect the new number of items in the deque. Note the following: If another process q succeeds in stealing items from p's deque concurrently to p's successful stealattempt, then p might fail in updating its own steairange, but it would still manage to update its bot and complete the steal successfully. Although trytosteal can be performed within a signalhandler, it is required that no local operations (namely pushbottom or pop Bottom ) are performed concurrently with trytosteal's execution. unsigned int *trytosteal(exdeque d, int plen){ ) rangelen = length of d.oldstealrange oldlen = length of d.deque IF plen> 2*rangeLen 2 return 0 (no need to steal) numtosteal = rangelen  plen/2 Copy first numtosteal items to the bottom of local deq newsrlen = max(l, 2"(i2)) [where 2"i <= oldlen < 2"(i+i)] CASupdate d.stealrange to contain newsrlen items IF CAS was performed successfully { update local bot to insert stolen items to the deque newdeqlen = new number of items at the local deque newsrlen=max(l,2"i) [where 2"(i+2)> newdeqlen >=2"(i+i)] CASupdate local stealrange to contain newsrlen items IF CAS was performed successfully prevstealrange = stealrange return numtosteal; ) ELSE return 0; 3 Analysis Figure 7: trytosteal method pseudocode In our analysis, we investigate the properties of the StealHalf algorithm under the probabilistic balancing policy, aiming to show that under reasonable assumptions, it keeps the system balanced. The probabilistic balancing policy we employ is very similar to the one described in [12], with the following main differences: 1. In [12], a process initiating loadbalancing can either steal items from or insert items to a randomly selected process, whereas in our scheme the initiating process can only steal items. We therefore call the former scheme symmetric probabilistic balancing and the latter asymmetric probabilistic balancing. 2. The model presented in [12] is synchronous in the sense that it assumes that computation proceeds in timesteps and that all processes attempt loadbalancing in the beginning of every timestep, whereas in the asynchronous model we investigate this cannot be assumed. [12] supplies a proof that symmetric probabilistic balancing keeps the system well balanced. It turns out, however, that this proof is incomplete. In the analysis presented in this section, we therefore supply an alternative proof for the symmetric case and then extend it also for asymmetric probabilistic balancing and specifically for the SteaiHalf algorithm. For lack of space, some of the proofs are omitted. 3.1 Notation Wherever possible, we follow the notation of [12]. To simplify the analysis, we assume that an execution is composed of a series of timesteps. In the beginning of each timestep, all processes flip biased coins to determine whether or not they should attempt balancing (in other words, they perform the balancing initiation code), and according to the result attempt or do not attempt balancing. Let Lp,t denote the number of items in p's workpile in the beginning of step t; also, let At denote the average system workload in the beginning of step t, namely: At  ~pep Lp,~ [Pl Process p decides to perform a balancing attempt at time t with probability: _e_ Lp,t ' for some constant 1 > # > O. When Lp,t equals O, we define  Lp,t to be 1. Ifp does decide to balance at time t, then it randomly selects another process q to balance with and tries to communicate with q to that effect. We denote this event by select(p, q, t) and therefore we have: 1 p(s~t(p,x,t))= ~,  . Lp,t n If at time t any one of the processes p or q selects the other in a balancing attempt, we denote this event by: select(p, q, t), namely: select(p, q, t) de] ~ = select(p, q, t) V selec~(q,p, t). If at time t, there are a few processes that initiate a balancing attempt with process p, then only one of them gets selected randomly. If process q is the one, we say that q approaches p at time t and we denote this event by approaches(q,p,t). If process q is the only process initiating a balancing attempt with p at time t, then approaches(q,p,t) also holds. If at time t, approaches(q,p,t) and p does not initiate a balancing attempt at time t, then p and q balance at time t. We denote a balancing event between p and q at time t by: balance(p, q, t). If at time t, approaches(q,p,t) and approaches(p,q,t), then p and q balance at time t. If at time t, approaches(p,q,t) and approaches(q,r,t), where p r, then q decides between p and r with equal probability. We denote this event by decide(q,x,t). Finally, if at time t both decide(p,q,t) and decide(q,p,t) hold, then balance(p, q, t) holds. The changes in the workpile size of any process p at time step t come from two sources: items which are added 285
Chord: A Scalable Peertopeer Lookup Service for Internet Applications
Chord: A Scalable Peertopeer Lookup Service for Internet Applications Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan MIT Laboratory for Computer Science chord@lcs.mit.edu
More informationObstructionFree Synchronization: DoubleEnded Queues as an Example
ObstructionFree Synchronization: DoubleEnded Queues as an Example Maurice Herlihy Computer Science Department Brown University, Box 1910 Providence, RI 02912 Victor Luchangco Mark Moir Sun Microsystems
More informationMaximizing the Spread of Influence through a Social Network
Maximizing the Spread of Influence through a Social Network David Kempe Dept. of Computer Science Cornell University, Ithaca NY kempe@cs.cornell.edu Jon Kleinberg Dept. of Computer Science Cornell University,
More informationThe Predecessor Attack: An Analysis of a Threat to Anonymous Communications Systems
The Predecessor Attack: An Analysis of a Threat to Anonymous Communications Systems MATTHEW K. WRIGHT, MICAH ADLER, and BRIAN NEIL LEVINE University of Massachusetts Amherst and CLAY SHIELDS Georgetown
More informationFreeze After Writing
Freeze After Writing QuasiDeterministic Parallel Programming with LVars Lindsey Kuper Indiana University lkuper@cs.indiana.edu Aaron Turon MPISWS turon@mpisws.org Neelakantan R. Krishnaswami University
More informationAbstract. 1. Introduction. Butler W. Lampson Xerox Palo Alto Research Center David D. Redell Xerox Business Systems
Experience with Processes and Monitors in Mesa 1 Abstract Butler W. Lampson Xerox Palo Alto Research Center David D. Redell Xerox Business Systems The use of monitors for describing concurrency has been
More informationThe Synergy Between Nonblocking Synchronization and Operating System Structure
The Synergy Between Nonblocking Synchronization and Operating System Structure Michael Greenwald and David Cheriton Computer Science Department Stanford University Stanford, CA 943059040 Abstract Nonblocking
More informationLinear Scan Register Allocation on SSA Form
Linear Scan Register Allocation on SSA Form Christian Wimmer Michael Franz Department of Computer Science University of California, Irvine {cwimmer, franz}@uci.edu Abstract The linear scan algorithm for
More informationVirtual Time. DAVID R. JEFFERSON University of Southern California 1. INTRODUCTION
Virtual Time DAVID R. JEFFERSON University of Southern California Virtual time is a new paradigm for organizing and synchronizing distributed systems which can be applied to such problems as distributed
More informationWhere s the FEEB? The Effectiveness of Instruction Set Randomization
Where s the FEEB? The Effectiveness of Instruction Set Randomization Ana Nora Sovarel David Evans Nathanael Paul University of Virginia, Department of Computer Science http://www.cs.virginia.edu/feeb Abstract
More informationSteering User Behavior with Badges
Steering User Behavior with Badges Ashton Anderson Daniel Huttenlocher Jon Kleinberg Jure Leskovec Stanford University Cornell University Cornell University Stanford University ashton@cs.stanford.edu {dph,
More informationHow to Use Expert Advice
NICOLÒ CESABIANCHI Università di Milano, Milan, Italy YOAV FREUND AT&T Labs, Florham Park, New Jersey DAVID HAUSSLER AND DAVID P. HELMBOLD University of California, Santa Cruz, Santa Cruz, California
More informationApproximately Detecting Duplicates for Streaming Data using Stable Bloom Filters
Approximately Detecting Duplicates for Streaming Data using Stable Bloom Filters Fan Deng University of Alberta fandeng@cs.ualberta.ca Davood Rafiei University of Alberta drafiei@cs.ualberta.ca ABSTRACT
More informationLow Overhead Concurrency Control for Partitioned Main Memory Databases
Low Overhead Concurrency Control for Partitioned Main Memory bases Evan P. C. Jones MIT CSAIL Cambridge, MA, USA evanj@csail.mit.edu Daniel J. Abadi Yale University New Haven, CT, USA dna@cs.yale.edu Samuel
More informationRmax A General Polynomial Time Algorithm for NearOptimal Reinforcement Learning
Journal of achine Learning Research 3 (2002) 213231 Submitted 11/01; Published 10/02 Rmax A General Polynomial Time Algorithm for NearOptimal Reinforcement Learning Ronen I. Brafman Computer Science
More informationCilk: An Efficient Multithreaded Runtime System
Cilk: An Efficient Multithreaded Runtime System Robert D. Blumofe Christopher F. Joerg Bradley C. Kuszmaul Charles E. Leiserson Keith H. Randall Yuli Zhou MIT Laboratory for Computer Science 545 Technology
More informationFast and Precise Hybrid Type Inference for JavaScript
Fast and Precise Hybrid Type Inference for JavaScript Brian Hackett Shuyu Guo Mozilla {bhackett,shu}@mozilla.com Abstract JavaScript performance is often bound by its dynamically typed nature. Compilers
More informationWhat s the Difference? Efficient Set Reconciliation without Prior Context
hat s the Difference? Efficient Set Reconciliation without Prior Context David Eppstein Michael T. Goodrich Frank Uyeda George arghese,3 U.C. Irvine U.C. San Diego 3 ahoo! Research ABSTRACT e describe
More informationConcurrent Tries with Efficient NonBlocking Snapshots
Concurrent Tries with Efficient Nonlocking Snapshots leksandar Prokopec EPFL aleksandar.prokopec@epfl.ch Nathan G. ronson Stanford ngbronson@gmail.com Phil agwell Typesafe phil.bagwell@typesafe.com Martin
More informationEverything You Always Wanted to Know About Synchronization but Were Afraid to Ask
Everything You Always Wanted to Know About Synchronization but Were Afraid to Ask Tudor David, Rachid Guerraoui, Vasileios Trigonakis School of Computer and Communication Sciences, École Polytechnique
More informationData Abstraction and Hierarchy
Data Abstraction and Hierarchy * This research was supported by the NEC Professorship of Software Science and Engineering. Barbara Liskov Affiliation: MIT Laboratory for Computer Science Cambridge, MA,
More informationOne VM to Rule Them All
One VM to Rule Them All Thomas Würthinger Christian Wimmer Andreas Wöß Lukas Stadler illes Duboscq Christian Humer regor Richards Doug Simon Mario Wolczko Oracle Labs nstitute for System Software, Johannes
More informationRobust Set Reconciliation
Robust Set Reconciliation Di Chen 1 Christian Konrad 2 Ke Yi 1 Wei Yu 3 Qin Zhang 4 1 Hong Kong University of Science and Technology, Hong Kong, China 2 Reykjavik University, Reykjavik, Iceland 3 Aarhus
More informationAsymmetric Memory Fences: Optimizing Both Performance and Implementability
Asymmetric Memory Fences: Optimizing Both Performance and Implementability Yuelu Duan, Nima Honarmand, and Josep Torrellas University of Illinois at UrbanaChampaign {duan11,torrella}@illinois.edu nhonarmand@cs.stonybrook.edu
More informationNew insights on the meanvariance portfolio selection from de Finetti s suggestions. Flavio Pressacco and Paolo Serafini, Università di Udine
New insights on the meanvariance portfolio selection from de Finetti s suggestions Flavio Pressacco and Paolo Serafini, Università di Udine Abstract: In this paper we offer an alternative approach to
More informationOPRE 6201 : 2. Simplex Method
OPRE 6201 : 2. Simplex Method 1 The Graphical Method: An Example Consider the following linear program: Max 4x 1 +3x 2 Subject to: 2x 1 +3x 2 6 (1) 3x 1 +2x 2 3 (2) 2x 2 5 (3) 2x 1 +x 2 4 (4) x 1, x 2
More informationControlFlow Integrity
ControlFlow Integrity Principles, Implementations, and Applications Martín Abadi Computer Science Dept. University of California Santa Cruz Mihai Budiu Úlfar Erlingsson Microsoft Research Silicon Valley
More informationGiotto: A TimeTriggered Language for Embedded Programming
Giotto: A TimeTriggered Language for Embedded Programming THOMAS A HENZINGER, MEMBER, IEEE, BENJAMIN HOROWITZ, MEMBER, IEEE, AND CHRISTOPH M KIRSCH Invited Paper Giotto provides an abstract programmer
More informationWHEN ARE TWO ALGORITHMS THE SAME?
WHEN ARE TWO ALGORITHMS THE SAME? ANDREAS BLASS, NACHUM DERSHOWITZ, AND YURI GUREVICH Abstract. People usually regard algorithms as more abstract than the programs that implement them. The natural way
More informationEfficient Processing of Joins on Setvalued Attributes
Efficient Processing of Joins on Setvalued Attributes Nikos Mamoulis Department of Computer Science and Information Systems University of Hong Kong Pokfulam Road Hong Kong nikos@csis.hku.hk Abstract Objectoriented
More information