• Abstract and Figures
• Public Full-text

Lo ck-Free Transactions for Real-Time Systems James H. Anderson, Srikanth Ramamurthy, Mark Moir, and Kevin Je ay Department of Computer Science, University of North Carolina at Chap el Hill tion phase or write phase) must b e executed as crit- Abstract ical sections [7,8]. Priorityinversion is often dealt with through the use of priority inheritance proto cols We show that previous algorithmic and scheduling or priority ceiling proto cols [14]. These proto cols dy- work concerning the use of lo ck-free ob jects in hard namically adjust transaction priorities to ensure that a real-time systems can b e extended to supp ort real-time transaction within a critical section executes at a pri- transactions on memory-resident data. Using our ap- ority that is suciently high to b ound the duration of proach, transactions are not susceptible to priorityin- any priorityinversion. This functionality comes at the version or deadlo ck, do not require complicated mecha- exp ense of additional overhead asso ciated with main- nisms for data-logging or for rolling back ab orted trans- taining information ab out transactions and the data actions, and are implemented as library routines that they access. require no sp ecial kernel supp ort. In addition, in many database systems, ma jor func- tional comp onents are implemented as separate mo d- 1 Intro duction ules (e.g., transaction manager, lo ck manager, etc.), eachofwhich consists of one or more pro cesses. Trans- In most real-time database systems, conventional actions interact with these mo dules byinvoking sp ecial mechanisms suchaslocks, timestamps, and serializa- primitives (e.g., Begin Transaction , End Transaction , tion graphs are used for concurrency control. The main Read , Write , Commit , Abort ). Although structuring a problem when using any of these mechanisms is that system in this way is attractive from a software engi- of handling con icting op erations. If an op eration of a neering standp oint, such an arrangement can result in transaction creates a con ict, then one of two strategies signi cantinterpro cess communicationoverhead. may b e used: either that transaction may b e blo cked, To summarize, although conventional concurrency or one or more of the transactions involved in the con- control schemes provide a general framework for real- ict may b e ab orted. When using con ict resolution time transactions, actual implementations of these schemes that employblocking, deadlo ckisakey issue, schemes can entail high overhead. In this pap er, we and mechanisms for deadlo ckavoidance or resolution prop ose a new approach for implementing real-time are required. In contrast, deadlo ck is not a problem transactions on memory-resident data on unipro ces- when using schemes that always resolve con icts by sors. In our approach, transactions are implemented ab orting transactions. However, with suchschemes, using a collection of library routines that hide from overhead asso ciated with undoing the e ects of par- transaction programmers all details asso ciated with tially completed transactions and then restarting them managing concurrency.Transactions implemented us- is a key issue. ing these routines are not susceptible to priority in- Most existing con ict resolution schemes for real- version or deadlo ck, and do not require complicated time database systems are susceptible to priorityin- mechanisms for data-logging or for rolling back ab orted version; a priority inversion o ccurs when a given trans- transactions. In addition, they do not require sp ecial action is blo cked by another transaction of lower pri- kernel supp ort or additional pro cesses for concurrency ority. Priorityinversion is a problem even for systems control; they therefore avoid interpro cess communica- that employ optimistic techniques, b ecause in such sys- tion overhead. tems, certain phases of a transaction (e.g., the valida- Our approach to implementing real-time transac- tions is based up on previous researchinvolving the use The rst three authors were supp orted, in part, byNSF contract CCR 9216421, and bya Young Investigator Award from of lo ck-free ob jects in real-time systems. An ob ject the U.S. Army Research Oce, grantnumber DAAH04-95-1- implementation is lock-free i it guarantees that, af- 0323. The third author was also supp orted by a UNC Alumni ter a nite numb er of steps of any op eration, some Fellowship. The fourth author was supp orted bygrants from op eration on the ob ject completes. Lo ck-free ob jects Intel and IBM. 1 typ e obj = record data : valtype; next : obj end at once. Suchanimplementation di ers from conven- shared variable queue tail : obj tional optimistic concurrency control proto cols in two pro cedure Enqueue(input : valtype) resp ects. First, our implementations do not use lo ck- lo cal variable old tail, new tail : obj ing. Therefore, they do not require sp ecial supp ort for tail := (input, NULL); new rep eat old tail := queue tail dealing with priorityinversion. Second, our implemen- until CAS2(queue tail, old tail > next, tations allow transactions to b e ab orted at arbitrary old tail, NULL, points during their execution without the aid of recov- tail, new tail) new ery pro cedures. An imp ortant implication of this p oint is that data-logging is greatly simpli ed. Figure 1: Lo ck-free enqueue op eration. The rest of this pap er is organized as follows. In Section 2, we review previous work involving the use of are usually implemented using \retry lo ops".Figure1 lo ck-free ob jects in real-time systems. Then, in Section depicts an example of a lo ck-free op eration | an en- 3, we outline our approach for implementing lo ck-free queue taken from a shared queue implementation given transactions. We end the pap er with concluding re- in [11]. In this example, an enqueue is p erformed by marks in Section 4. trying to thread an item onto the tail of the queue us- 1 ingatwo-word compare-and-swap (CAS2) instruction. This threading is attempted rep eatedly until it suc- ceeds. Note that the queue is never actually \lo cked". 2 Lo ck-Free Ob jects Using lo ck-free ob ject implementations, ob jects are We b egin this section by reviewing previous work on optimistically accessed without lo cking, and an ac- scheduling hard real-time tasks that share lo ck-free ob- cess is retried if an interference o ccurs. Op erations jects. We then consider the issue of hardware supp ort are atomically validated and committed byinvoking a for lo ck-free synchronization. strong synchronization primitive(like CAS2). In Fig- ure 1, this validation step can fail for a task only if a higher-priority task p erforms a successful CAS2 be- 2.1 Scheduling with Lo ck-Free Ob jects tween the read of queue tail by and the subsequent CAS2 op eration by . Although it should b e clear that lo ck-free ob jects do From a real-time p ersp ective, lo ck-free ob ject imple- not give rise to priorityinversions, it may seem that un- mentations are of interest b ecause they avoid prior- b ounded retry lo ops render such ob jects useless in real- ityinversions with no kernel supp ort. On the surface, time systems. Nonetheless, Anderson, Ramamurthy, however, it is not immediately apparentthatlock-free and Je ayhaveshown that if tasks on a unipro ces- shared ob jects can b e employed if tasks must adhere sor are scheduled appropriately,thensuch lo ops are to strict timing constraints. In particular, rep eated indeed b ounded [4]. Wenow explain intuitively why interferences can cause a given op eration to takean such b ounds exist. For the sake of explanation, let us arbitrarily long time to complete. Fortunately,such call an iteration of a retry lo op a successful update if it interferences can b e b ounded byscheduling tasks ap- successfully completes, and a failedupdate otherwise. propriately [4]. As explained in the next section, the Thus, a single invo cation of a lo ck-free op eration con- key to scheduling such tasks is to allow enough spare sists of anynumb er of failed up dates followed by one pro cessor time to accommo date the failed ob ject up- successful up date. dates that can o ccur over anyinterval. The number Consider two tasks and that access a common i j of failed up dates in suchaninterval is b ounded bythe lo ck-free ob ject B . Supp ose that causes to exp eri- i j numb er of task preemptions within that interval. ence a failed up date of B . On an unipro cessor, this can In this pap er, we show that previous work on lo ck- only happ en if preempts the access of and then i j free ob jects can b e extended to apply to lo ck-free trans- up dates B successfully.However, preempts only i j actions on memory-resident databases. Our approach if has higher prioritythan .Thus, at each prior- i j to implementing such transactions is to rst imple- ity level, there is a correlation b etween failed up dates menta multi-word CAS primitive(MWCAS). This primi- and task preemptions. The maximum number of task tive can then b e used as the basis for a lo ck-free retry preemptions within a time interval can b e determined lo op in which op erations on many ob jects are validated from the timing requirements of the tasks. Using this information, it is p ossible to determine a b ound on the 1 The rst two parameters of CAS2 are shared variables, the numb er of failed up dates in that interval.

Load more

  8

Copy Link