Formal Verification of Lock-Free Algorithms

More documents

Recommendations

Info

Top a b c null Figure 1. Example of a Stack representation CAS(Old,New,G : Pointer){ if G = Old then {G := New; return TRUE; } else return FALSE; } Figure 2. The atomic CAS operation 1 2 3 4 5 6 7 8 9 10 CPOP(Top : Pointer ) { repeat OTop := Top ; if OTop = null then return empty; ONxt := OTop .nxt ; Res := OTop .val ; until CAS(OTop , ONxt , Top ); return Res } Figure 4. The pop operation field for the data value and a .nxt pointer to refer to the succeeding node. The end of the stack is marked with the null pointer. The entry point of the stack, i.e. the top cell, is referenced by the global variable Top. The push and pop operations consist of two phases. First, the needed data is prepared without changing the main data structure, e.g. storage is allocated or data are read. In a second phase, it is attempted to change the stack data structure in a single atomic step. If this atomic step fails (e.g. because the data structure has changed), the main data structure is not changed and the algorithm repeats phase one. To change the stack atomically, a compare-and-swap (CAS) command is used. Pseudocode for this operation is given in Figure 2. The CAS command compares a local pointer Old with a global pointer G, where Old is typically a value of G, that was read earlier by the process. If both pointers are identical, G is set to a new value New and the CAS command succeeds. If the values are different, G is left unchanged and the CAS command fails. All usual multi-core processors support atomic CAS instructions (e.g. CMPXCHG on x86 processors) or equivalent instructions. The push algorithm is depicted in Figure 3. Parameters of CPUSH are the value input value V, which should be placed on top of the stack, and a reference to the Top pointer. Since each invocation of CPUSH runs in parallel with calls to CPUSH or CPOP from other processes, Top may change at any time while the algorithm is executed. Variables UNew and UTop are local pointer variables. 1 2 3 4 5 6 7 8 CPUSH(V : Data, Top : Pointer){ UNew := new(Node); UNew .val := V; repeat { UTop := Top ; UNew .nxt := UTop ; } until CAS(UTop , UNew , Top ) } Figure 3. The push operation The algorithm starts by allocating a new cell on the heap and writing the input value V into the newly allocated node (line 2 and 3). After that the algorithm loops, as long as the insertion of the new cell in the stack fails (line 4 to 7). Inside the loop the pointer of the current top cell is copied to the local variable UTop and the .nxt-pointer of the previously allocated cell is set to the current top cell (line 5 and 6). Finally, the algorithms attempts to add the new data value to the top of the stack data structure by a CAS operation (line 7). If the current Top is still the same as it was in line 5, the previously allocated cell UNew contains the correct .nxt -pointer and Top can be set to UNew . If the top of stack was changed by another push or pop process in the meantime, the CAS operation fails and the loop is reiterated. The pop algorithm, shown in Figure 4, is very similar. The only difference is that it has to be checked, whether the stack is empty or not (line 4). In case of an empty stack, a special value empty is returned. 3. Linearizability and Lock-Freedom The usual correctness criteria for lock-free algorithms are linearizability for safety and lock-freedom for liveness. Linearizability was defined by Herlihy & Wing [5]. It is based on the visible inputs and outputs of processes. Formally a history is defined as a list of invoke and return events. An invoke event inv(p,op,in) is added to the history, when process p invokes operation op with input in. Similarly a return event ret(p,op,out) is added when process p returns with output out from operation op. In our example a possible history created by two processes p and q is H = [inv(p,push,3), inv(q,push,4), ret(p,push,−), ret(q,push,−), inv(q,pop,−), ret(q,pop,4)] where the − indicates no input/output. A history is linearizable if it can be reordered to a sequential history, where each invoke is directly followed by the corresponding return. The reordering must respect the order that was present in the original history: an operation whose invoke happened after the return of another operation, must end up in the same 14 Authorized licensed use limited to: Technische Universitat Kaiserslautern. Downloaded on January 18, 2010 at 11:43 from IEEE Xplore. Restrictions apply.
order in the sequential history. For the history H above two linearizations are possible. [inv(q,push,4), ret(q,push,−), inv(p,push,3), ret(p,push,−), inv(q,pop,−), ret(q,pop,4)]. and [inv(p,push,3), ret(p,push,−), inv(q,push,4), ret(q,push,−), inv(q,pop,−), ret(q,pop,4)] The first history is not compatible with the semantics of a stack (if 3 was pushed last, then the pop should return 3, not 4), but the second is. Therefore H is linearizable. A concurrent implementation of a data type is linearizable, if every history it creates is linearizable. The definition given is difficult to use for verification. Therefore all work we are aware of has used the following simpler requirement: in between the invoke and return of every operation a linearization point must exist, such that the operation can be thought of as executing atomically at that point. In simple examples, the linearization point can be identified as a specific line of the source code: for the push operation the CAS instruction is the linearization point. That the original definition is difficult to use has already been noted in the original work [5], and an alternative definition based on so-called possibilities is given that is closer to the simple requirement. In [11] we have formalized the original definition as well as possibilities, and have formally proved that they are equivalent. Linearizability can be viewed as a correctness criterion for refinement. In the example of the previous section, stack operations are refined by programs working on pointer structures. In [12] and [11] we have shown, that it is possible to view linearizability as an instance of non-atomic data refinement. [12] is based on encoding the control structure of the operations in CSP. Single steps of the algorithm are defined as Z operations. [11] replaces the CSP control structure with program counters, which allowed to mechanize the proofswithKIV.Interleavingisrealizedbyusingpromotion. To verify linearizability [11] and [13] give modular proof obligations, that reduce the problem to two processes by exploiting their symmetry. The stack algorithm is used as a running example. The resulting proof obligations can be verified using predicate logic alone. They resemble the Owicki- Gries technique [14] for proving program correctness. Linearizability guarantees that operations will return correct results, but not their termination. Indeed, termination of a single push algorithm (and therefore liveness of the process) cannot be guaranteed, since it is possible that each loopiterationisinterceptedbyanotherpushorpopoperation that modifies the stack and causes the CAS operation to fail. The algorithm does not satisfy the Wait-Freedom criterion, that requires that each operation must finish within a finite number of (his own) steps. This is a disadvantage compared to algorithms using locks which usually satisfy waitfreedom. Instead lock-free algorithms satisfy the weaker criterion of Lock-Freedom which only requires, that when several operations are currently running, at least one of them will terminate. This implies that as soon as no new operations are started any more, all running operations will eventually terminate. For the stack example the criterion is satisfied: if a push or pop operation must retry due to a failed CAS, this was caused by another push or pop operation, that successfully modified the stack and therefore terminated. 4. Current Work Acommon technique toavoid proofs thathave toconsider theconcurrentsystemasawholeiscompositionalreasoning, which was first formulated in [15] by Dijkstra. The idea of this technique is to split the system into several subcomponents. Then, the overall property is proved by combining properties of the subcomponents. A common compositional proof technique is the relyguarantee paradigm, which was introduced by Jones [16] and by Misra and Chandy [17] (under the name assumptioncommitment). The basic idea of this paradigm is, that each component can make specific assumptions about its environment in order to guarantee a specific behavior. Usually a rely-guarantee technique provides a theorem, that specifies in a number of proof obligations how the various assumptions and guarantees have to be connected in order to show the property for the overall system. Ideally, these proof obligations consider only single subcomponents and are of feasible size. Most rely-guarantee techniques use either a semantic framework or temporal logics. Examples can be found e.g. in [18], [19], [20]. Our own approach uses an expressive temporal logic [7], [6] that is a variant of interval temporal logic (ITL, [21]). ITL extends linear temporal logic (LTL) by considering infinite as well as finite runs (called intervals). Therefore termination is expressible. The semantics of a formula is a set of intervals, which makes the formula valid. Sequential as well as parallel programs are just specific formulas, since their semantics is also a set of intervals (the set of possible runs). This makes it possible to mix programs and formulas freely: components can be abstracted to their properties. KIV supports deduction for interleaved programs (used to model the stack example), as well as asynchronous parallel programs and statecharts [22], [23]. Since programs are explicit formulas, there is no need to encode algorithms such as the push and pop algorithm into transition systems, as most other approaches (e.g. TLA [24]) do. Instead our deduction approach extends the well-known principle of symbolic execution and induction [25] to parallel programs. Using this approach we have mechanized a compositionality theorem for linearizability as a special case of trace refinement. We also verified the resulting proof obligations for the stack example [26],[9] from Section 2. In a master’s thesisoneofourstudents[27]hasmechanizedlinearizability 15 Authorized licensed use limited to: Technische Universitat Kaiserslautern. Downloaded on January 18, 2010 at 11:43 from IEEE Xplore. Restrictions apply.
Page 1: 2009 Ninth International Conference
Page 5 and 6: [7] M. Balser, S. Bäumler, W. Reif

Formal Verification of Lock-Free Algorithms

Create successful ePaper yourself

Delete template?

Save as template?