
Room Synchronizations Guy E. Blelloch Perry Cheng Computer Science Department void push(val y) { it do es not matter what order relative to the increments the int j; values are inserted. enterRoom(PUSHROOM); Therefore, if we can separate the pushes from the p ops, void push(val y) { j = fetchAdd(&top,1); wewould have a safe implementation of a stack. Ro om syn- int j; A[j] = y; j = fetchAdd(&top,1); exitRoom(); chronizations allow ustodothisasshown in Figure 1(b). } A[j] = y; The ro om synchronization guarantees that no two users will } ever simultaneously b e in the PUSHROOM and POPROOM,sothe val pop() { push and p op instructions will never b e interleaved. How- val x; val pop() { ever, it will allowanynumb er of users to b e in either the int k; int k; val x; push or p op ro om simultaneousl y. enterRoom(POPROOM); k = fetchAdd(&top,-1); k = fetchAdd(&top,-1); In the full pap er [4] weshow that using our ro om syn- if (k <= 0) { if (k <= 0) { chronization algorithm (a) asynchronous accesses (pushes or fetchAdd(&top,1); fetchAdd(&top,1); p ops) can arriveatany time, (b) every access is serviced in x = EMPTY; x = EMPTY; 2 time prop ortional to the time of a fetch-and-add , and (c) } } that this implements a linearizab le stack. The exp eriments else x = A[k-1]; elsex=A[k-1]; describ ed in Section 4 are based on a variant of this stackin return x; exitRoom(); } return x; whichmultiple elements are pushed or p opp ed within each } ro om. (b) (a) Outline. The pap er is organized as follows. Section 2 formally de nes ro om synchronizati ons, and presents an al- gorithm that provably implements them. Section 3 shows Figure 1: The co de for a parallel stack. (a) Do es not howroomsynchronizations can b e e ectively used to imple- work if the push and p op are interleaved in time. (b) ment shared queues and dynamic shared stacks. Section 4 Avoids this problem using a ro om synchronization. presents our exp erimental results. Section 5 discusses fur- ther issues and related work, and Section 6 concludes. degrades linearly with the numb er of pro cessors (b ecause tialized ), our version scales almost p er- accesses are sequen 2. ROOM SYNCHRONIZATIONS fectly,beyond an initial cost for going from one to two pro- The ro om synchronization problem involves a set of m cessors. The ro om synchronizatio ns intro duced in this pap er ro oms, and a set of p indep endent users who wish to access have b een incorp orated into our real-time garbage collector the ro oms. A user wishing access to a ro om calls an En- co de [5], where they are used extensively. ter Ro om primitive, which returns once the user is granted One disadvantage of ro om synchronization s is that if a p ermission to enter the ro om. The user is then said to b e user fails or stops while inside a ro om, the user will blo ck inside the ro om. When done with the ro om, the user exits other users from entering another ro om. This prop ertyis the ro om by calling an Exit Ro om primitive. The ro oms clearly not desirable under all conditions, but in manycon- synchronization construct must ensure that at any p ointin ditions, includin g the garbage collector, it is not a problem. time, there is at most one \op en" ro om with users inside it. We discuss this issue in Section 5. However, anynumb er of users can b e inside the op en ro om. eprovide details on the ro om synchro- 1.1 A Motivating Example In this section, w nization problem, discuss necessary and desirable prop erties To motivate our problem, we consider implementing a par- for proto cols implementing ro om synchronizatio n, presenta allel stack using a fetch-and-add. We assume the stackis proto col that implements ro om synchronizatio n, and show stored in an array A and the index top p oints to the next that this proto col satis es all these prop erties. free lo cation in the stack (the stack grows from 0 up). The tr,cnt) op eration adds cnt to the contents of fetchAdd(p 2.1 Primitives lo cation ptr and returns the old contents of the lo cation (b e- The basic primitives of ro om synchronization are: fore the addition). We assume this is executed atomically. Consider the stack co de shown in Figure 1(a). Assuming a Create Ro oms. Given a p ositiveinteger m,createa constant-time fetchAdd, the push and pop op erations will ro oms ob ject R for a set of m ro oms, and return a p ointer take constant time. The problem is that they can work (a reference) to R. There can b e multiple ro oms ob jects at incorrectly if a push and pop are interleaved in time. For the same time. example, in the following interleaving of instructions Enter Ro om. Given a p ointer to a ro oms ob ject R and aroomnumber i, try to enter ro om i of R. Return when j = fetchAdd(&top,1); // from push the user has succeeded in entering the ro om. When the k = fetchAdd(&top,-1); // from pop primitive returns, the user is said to b e inside the ro om. A x = A[k-1]; // from pop A[j] = y; // from push ro om with a user inside is said to b e open. Exit Ro om. Given a p ointer to a ro oms ob ject R, exit the p op will return garbage. Without an atomic op eration the ro om in R that the user is currently inside. Because the that changes the counter at the same time as mo difying the user can b e inside at most one ro om in R, there is no need stack element, we see no simple way of xing this problem. to sp ecify the ro om numb er. When a user requests to exit One should note, however, that anyinterleaving of twoor a ro om, it is no longer considered to b e inside the ro om. If more pushes or two or more p ops is safe. Consider pushes. 2 The fetchAdd reserves a lo cation to put the value y, and the This is under certain assumptions ab out all pro cessors write inserts the value. Since the counter is only increasing, making progress. 123 Asynchrony is mo deled by the fact that actions from dif- there are no users remaining inside the ro om, the ro om is ferent agent pro cesses can b e interleaved in an arbitrary said to b e closed. manner; thus one agentmayhavemany actions b etween DestroyRooms. Given a p ointer to a ro oms ob ject, actions by another agent. We will consider various fairness deallo cate the ro oms ob ject. metrics for executions and for ro om accesses. A weak form Other primitives. In addition to these four basic primi- of fairness among the agent actions is the following: An ex- tives, there is a Change Ro om primitive, whichisequivalent ecution is weakly-fair if it is either (a) nite and no agent to an Exit Ro om followed byanEnter Ro om, but with the action is enabled in the nal state, or (b) in nite and each guarantee of immediate entry into the requested ro om if it agent has in nitely many opportunities to p erform an ac- is the next ro om to b e op ened. There is also an Assign Exit tion (either there is an action by the agentornoactionis Co de primitive, discussed at the end of Section 2.3. enabled). Certain actions are sp ecially designated as external ac- The Enter Ro om and Exit Ro om primitives can b e viewed tions; these are the (only) actions in which a user communi- as the counterparts to the \trying" (e.g., lo ck) and \exit" cates with its agent. For ro om synchronizatio n, the external (e.g., unlo ck) primitives for the mutual exclusion problem. actions for a user j (and its agent) are: As with the mutual exclusion problem, what the users do while inside the ro om (or critical section) is part of the appli- EnterRo omReq (i): the action of user j signalli ng to j cation and not part of the synchronization construct. This its agent p a desire to enter ro om i. j enables the generality of the primitive, as the same construct can b e used for a variety of applicatio ns. The drawbackis EnterRo omGrant (i): the action of agent p signalli ng j j that, as with mutual exclusion, the construct relies on the to user j that its Enter Ro om request has b een granted. application to alternate entering and exiting requests bya ExitRo omReq : the action of user j signalli ng to its given user. j The Create Ro oms and Destroy Ro oms primitives are ex- agent p a desire to exit its currentroom. j ecuted once for a given ro oms ob ject, in order to allo cate ExitRo omGrant : the action of agent p signalling to j j and initiali ze the ob ject prior to its use and to deallo cate user j that its Exit Ro om request has b een granted.
Details
-
File Typepdf
-
Upload Time-
-
Content LanguagesEnglish
-
Upload UserAnonymous/Not logged-in
-
File Pages12 Page
-
File Size-