Software fault tolerance of concurrent programs using controlled re-execution

Abstract

A method for fault tolerance in concurrently executing computer programs is presented. The present invention controls the re-execution of concurrent programs in order to avoid a recurrence of synchronization failure. The invention (i) traces an execution, (ii) detects a synchronization failure, (iii) determines a control strategy, and (iv) re-executes under control. control is achieved by tracing information during an execution and using this information to add synchronizations during the re-execution.

Description

This application is a conversion from and claims priority of U.S. Provisional Application No. 60/159,253, filed Oct. 13, 1999.

FIELD OF THE INVENTION

The present invention is generally directed to methods for correcting synchronization faults in concurrently executed computer programs and, more particularly, to methods and systems for fault tolerance of concurrently executed software programs using controlled re-execution of the programs.

BACKGROUND OF THE INVENTION

Concurrent programs are difficult to write. The programmer is presented with the task of balancing two competing forces: safety and liveness. Frequently, the programmer leans too much in one of the two directions, causing either safety failures (e.g. races) or liveness failures (e.g. deadlocks) Such failures arise from a particular kind of software fault (bug), known as a synchronization fault. Studies have shown that synchronization faults account for a sizeable fraction of observed software faults in concurrent programs. Locating synchronization faults and eliminating them by reprogramming is always the best strategy. However, many systems must maintain availability in spite of software failures. Concurrent programs include all parallel programming paradigms such as multi-threaded programs, shared-memory parallel programs, message-passing distributed programs, distributed shared-memory programs, etc. A parallel entity may be referred to as a process, although in practice it may also be a thread.

Traditionally, it was believed that software failures are permanent in nature and, therefore, they would recur in every execution of the program with the same inputs. This belief led to the use of design diversity to recover from software failures. In approaches based on design diversity, redundant modules with different designs are used, ensuring that there is no single point-of-failure. Contrary to this belief, it was observed that many software failures are, in fact, transient (they may not recur when the program is re-executed with the same inputs). In particular, the failures caused by synchronization faults are usually transient in nature.

The existence of transient software failures motivated a new approach to software fault tolerance based on rolling back the processes to a previous state and then restarting them (possibly with message reordering), in the hope that the transient failure will not recur in the new execution. Methods based on this approach have mostly relied on chance in order to recover from a transient software failure. In the special case of synchronization faults, however, it is desirable to do better.

It would therefore be desirable to be able to bypass a synchronization fault and recover from the resulting failure.

SUMMARY OF THE INVENTION

The present invention controls the re-execution of concurrent programs in order to avoid a recurrence of the synchronization failure. The invention provides a method of (i) tracing an execution, (ii) detecting a synchronization failure, (iii) determining a control strategy, and (iv) re-executing under control.

Control is achieved by tracing information during an execution and using this information to add synchronizations during the re-execution.

In accordance with the present invention, a method of providing fault tolerance in concurrently executing computer programs by controlling the re-execution of concurrent programs in order to avoid a recurrence of synchronization failures is provided, comprising:

(a) tracing the execution of concurrent programs;

(b) detecting synchronization failures resulting from said execution of the concurrent programs; and

(c) applying a control strategy, based on said detection of failures, for said execution of the concurrent programs.

Also in accordance with the present invention, application of a control strategy includes causing a re-execution of said concurrent programs under a control derived from tracing information during an execution, and wherein said control includes using said information to add synchronizations to said concurrent programs during re-execution.

DETAILED DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the invention and for application of further advantages thereof, reference is now made to the following description or preferred embodiments taken in conjunction with the accompanying drawings, in which:

FIG. 1 is an illustration of a tracing and controlling during rollback recovery;

FIG. 2 is an illustration of variants of Off-line exclusions;

FIG. 3 is an illustration of the algorithm used for Off-line independent read-write mutual exclusion;

FIG. 4 is an flow diagram showing the main steps of the invention; and

FIG. 5 is an illustration of tolerating races in a concurrent execution.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

In accordance with the present, methods for tolerating transient synchronization failure in software is provided. The present invention controls the re-execution of concurrent programs, based on information traced during a failed execution. The following description will describe the management of races, tracing, failure detection, and re-execution under control in great depth.

Referring to FIG. 1, illustrated is an example of tracing and controlling during rollback recovery. To illustrate what determining a control strategy involves, consider the execution shown in FIG. 1(a). CS1-CS4 are the critical sections of the execution. The synchronizations between processes are shown as arrows from one process execution to another. A synchronization ensures that the execution after the head of the arrow can proceed only after the execution before the tail has completed. A race occurs when two critical sections execute simultaneously. For example, CS1 and CS2 may have a race, since the synchronizations do not prevent them from executing simultaneously. A control strategy is a set of added synchronizations that would ensure that a race does not occur. The race can be avoided by adding synchronizations, shown as broken arrows in FIG. 1(b).

The present invention allows for the development of a control strategy by determining which synchronizations to add to an execution trace in order to tolerate a synchronization fault during the re-execution of a computer program, or programs, encountering fault. This proves to be an important problem in its own right and can be applied in areas other than software fault tolerance, such as concurrent debugging. The problem is generalized using a framework known as the off-line predicate control problem. The problem, as it applied to debugging, was introduced in a paper entitled "Predicate control for active debugging of distributed programs," by A. Tarafdar and V. K. Garg. IEEE Proceedings of the 9^th symposium on Parallel and Distributed Processing, Orlando, USA, April 1998. Informally, off-line predicate control specifies that, given a computation and a property on the computation, one must determine a controlled computation (one with more synchronizations) that maintains the property (used is the term computation for a formal model of an execution). Previous attempts solved the predicate control problem for a class of properties called disjunctive predicates. Applying the results of the Tarafdar et al. study to software fault tolerance would mean avoiding synchronization failures of the form: l₁{circumflex over ( )}l₂{circumflex over ( )}l₃, where l₁ is a local property specified on process P₁. For example, if l₁ specifies that a server is unavailable, the synchronization failure is that all servers are unavailable at the same time.

The invention addresses a class of off-line predicate control problems, characterized by the mutual exclusion property, that is especially useful in tolerating races. Four classes of mutual exclusion properties are considered: off-line mutual exclusion, off-line readers writers, off-line independent mutual exclusion, and off-line independent read-write mutual exclusion. For each of these classes of properties, necessary and sufficient conditions under which the problem may be solved are determined. Furthermore, an efficient algorithm that solves the most general of the problems, off-line independent read-write mutual exclusion, is presented, which also solves each of the other three problems. The algorithm takes O(np) time, where n is the number of concurrent processes and p is the number of critical sections.

The said problems have been termed off-line problems to distinguish them from their more popular on-line variants (i.e. the usual mutual exclusion problems). The difference between the on-line and off-line problems is that in the on-line case, the computation is provided on-line, whereas in the off-line case, the computation is known a priori. Ignorance of the future makes on-line mutual exclusion a harder problem to solve.

In general, in on-line mutual exclusion, one cannot avoid deadlocks without making some assumptions (e.g. critical sections do not block). Thus, on-line mutual exclusion is impossible to solve. To understand why this is true, consider the scenario in FIG. 1. Any on-line algorithm, being unaware of the future computation, would have a symmetric choice of entering CS1 or CS2 first. If CS2 is entered first, it would result in a deadlock. An off-line algorithm, being aware of the future computation, could make the correct decision to enter CS1 first and add a synchronization from CS1 to CS2. There will always be scenarios where on-line mutual exclusion algorithms will fail, resulting in either race conditions or deadlocks. In such scenarios, controlled re-execution based on off-line mutual exclusion becomes vitally important.

The model that is now presented is of a single execution of the concurrent program. The model is not at the programming language level, but at a lower level, at which the execution consists of a sequence of states for each process and the communications that occurred among them, let S be a finite set of elementary entities known as states. S is partitioned into subsets S₁, S₂, . . . , S_n, where n>1. These partitions correspond to n processes in the system. A subset G of S is called a global state if ∀i: |G∩S_i|=1. Let G_i denote the unique element in G∩S_i. A global predicate is a function that maps a global state onto a boolean value.

A computation is a partial order → on S such that ∀i:→_i is a total order on S_i, where →_i represents → restricted to the set S_i. Note that the states in a single process are totally ordered while the states across processes are partially ordered. We will use →, →^k, →^c to denote computations, and ∥, ∥^k, ∥^o to denote the respective incomparability relations (e.g. s∥t≡(s≯t){circumflex over ( )}(t≯s)). Given a computation → and a subset K of S, →-consistent (K)≡∀s, tεK s∥t. In particular, a global state may be →-consistent. The notion of consistency indicates when a set of states could have occurred concurrently in a computation.

A computation → is extensible in S if:

∀KS:→-consistent (K) ∀global state GK:→-consistent (G)

Intuitively, extensibility allows for the extension of a consistent set of states to a consistent global state. Any computation in S can be made extensible by adding "dummy" states to S. Therefore, it can be implicitly assumed that any computation is extensible.

Given a computation →, let ≦ be a relation on global states defined as: G≦H≡∀i: (G_i→i H_i) (G_i≡H_i). It is a well-known fact that the set of →-consistent global states is a lattice with respect to the ≦ relation. In particular, →-glb(G,H) is used for the greatest lower bound of G and H with respect to → (so, →-glb(G,H)_i≡→_i-min (G_i,Hi)). If G and H are →-consistent, then →-glb(G,H) is also →-consistent.

Given a computation → and a global predicate B, a computation →^c is called a controlling computation of B in → if (1) →→^c, and (2) ∀G:→^c-consistent(G)B(G). This indicates that a controlling computation is a stricter partial order (containing more synchronizations). Further, any global state that may occur in the controlling computation must satisfy the specified global predicate. Thus, the problem of finding a controlling computation is to add synchronizations until all global states that violate the global predicate are made inconsistent.

In the paper by Tarafdar et al., it was proved that the Off-line Predicate Control is NP-Hard. Therefore, it is important to solve useful restricted forms of the Off-line Predicate Control Problem. Since it is desirable to avoid race conditions, the general problem is restricted by letting B specify the mutual exclusion property.

Referring to FIG. 2, an illustration of variants of off-line mutual exclusion is provided. The simplest specification for mutual exclusion is: no two critical sections execute at the same time. This corresponds to the semantics of a single exclusive lock for all the critical sections. The corresponding problem can be referred to as an Off-line Mutual Exclusion Problem. This can be generalized to the Off-line Readers Writers Problem by specifying that only critical sections that "write" must be exclusive, while critical sections that "read" need not be exclusive. This corresponds to the semantics of read-exclusive-write locks. Another way to generalize the Off-line Mutual Exclusion Problem is to allow the semantics of independent locks. In this Off-line Independent Mutual Exclusion Problem, no two critical sections of the same lock can execute simultaneously. Finally, critical sections may be associated with the semantics of independent read-exclusive-write locks. This is the Off-line Independent Read-Write Mutual Exclusion Problem. FIG. 2 illustrates the relative generality of the four problems.

In traditional on-line mutual exclusion, there has been no "independent" variant, since it trivially involves applying the same algorithm for each lock. However, in off-line mutual exclusion, such an approach will not work, since the synchronizations added by each independent algorithm may cause deadlocks when applied together.

For the practitioner, an algorithm which solves Off-line Independent Read-Write Mutual Exclusion would suffice, since it can be used to solve all other variants. For the purpose of describing the invention in straight-forward terms, however, the simplest off-line mutual exclusion Problem will be described in generalized steps. For each problem, the necessary and sufficient conditions for finding a solution will also be described.

Off-line Mutual Exclusion is a specialization of Off-line Predicate Control to the following class of global predicates:

B_mutex(G)≡∀distinct s,t∈G: (critical(s)critical(t))

where critical is a function that maps a state onto a boolean value. Thus, B_mutex specifies that at most one process may be critical in a global state.

Based on the critical boolean function on states, critical sections are defined as maximal intervals of critical states. More precisely; given a critical function on S and a computation→on S, a critical section, CS, is a non-empty, maximal subset on a S_i such that: (1) ∀s∈CS: critical(s), and (2) ∀s,t∈CS: ∀u∈S_i: s→u→t u∈CS.

Let CS.first and CS.last be the minimum and maximum states respectively in CS (w.r.t. →_i). Let be a relation on critical sections defined as: CSCS'≡CS.first→CS'.lastCS≠CS' Thus, orders a critical section before another if some state in the first happened before some state in the second. Note that may have cycles.

All computations will have the same total order →_i for each S_i. Therefore, the set of critical sections will not change for each computation. However, the relation will change, in general. For computations →, →^k, and →^c, the relation on critical sections will be denoted as , ^k and ^c respectively.

Theorem 1 (Necessary Condition) For a computation → of S, and a global predicate B_mutex,

a controlling computation of B_mutex in → exists has no cycles

Proof: The contrapositive is proved. Let have a cycle, say CS₁CS₂ . . . CS_mCS₁, (m≧2) and let →^c be a computation such that →^c. Since →^c cannot have a cycle, at least one of: CS₁.last≯^cCS₂.first, CS₂.last≯^cCS₃.first, . . . , and CS_m.last≯^cCS₁.first must hold. Without loss of generality, let CS₁.last≯^cCS₂.first. Also CS₂.last≯^cCS₁.first (since CS₁CS₂) Since →^c is extensible, s₂ can be defined as the maximum state in S₂ such that CS₁.last∥^c s₂ and s₁ as the maximum state in S₁ such that CS₂.last∥^c s₁. By extensibility of →^c, →^c-consistent global states G₁ and G₂ can be found containing {CS₁.last, s₂} and {CS₂.last, s₁} respectively. There are now two cases:

Case 1: [s₁∈CS₁s₂∈CS₂] In this case B_mutex. (G₁).

Case 2: [s₁∉CS₁s₂∉CS₂] Since s₁∉CS₁, there are two ways to position s₁: (a) s₁ →^c CS₁.first or (b) CS₁.last→^c s₁. In sub-case (a), since CS₂.last≯^cCS₁.first, either CS₂.last∥^cCS₁.first or CS₁.first→^cCS₂.last, which gives s₁→^cCS₂.last. Both possibilities contradict the definition of s₁. This leaves sub-case (b) as the only possibility. Therefore, CS₁.last→^cs₁. Similarly, CS₂.last→^cs₂ can be proved. Let H=→^c-glb(G₁, G₂). H contains CS₁.last and CS₂.last and, so, (H). Further, H is →^c-consistent (by the lattice property).

So in either case, →^c is not a controlling computation of B_mutex in →.

Theorem 2 (Sufficient Condition) For a computation → of S and a global predicate B_mutex,

has no cycles a controlling computation of B_mutex in → exists

Proof: Since has no cycles, all of the critical sections can be arranged in a sequence: CS₁CS₂, . . . Cs_m such that Cs_i→Cs_ii<j. Let →^c be defined as (→∪{(CS₁.last, CS_i+1.first)|1≦i≦m-1})⁺, where ( )⁺ is the transitive closure. Clearly →→^c. In the next paragraph, →^c is proved a partial order. Assume that there is a global state G such that B_mutex(G). Let Cs_i and Cs_j be the two critical sections to which s and t belong respectively. w.l.o.g, let i<j. Therefore, s→^ct, and →^c-consistent(G). Therefore, →^c-consistent(G) B_mutex(G). So →^c is a controlling computation of B_mutex in →.

The remaining obligation of proof is that →^c is a partial order. To this end, let →^k be defined as: (→∪{(CS_i.last, CS_i+1.first)|1≦i≦k-1})⁺. The following claim can be made: Claim:&forall;1≦k≦m: (1)→^k is a partial order, and (2) CS_iCs_ji<j Clearly →^c=→^m and so this claim implies that →^c is a partial order.

Proof of Claim: (by Induction on k)

Base Case: Immediate from →=→¹.

Inductive Case: We make the inductive hypothesis that →^k-1 is a partial order, and that CS_i^k-1CS_ji<j. The definition of →^k can be rewritten as: (→^k-1∪{(CS_k-1.last, CS_k.first)})⁺. First it is demonstrated that →^k is irreflexive and transitive (which together imply asymmetry).

(i) Irreflexivity: Let s→^kt. There are two possibilities: either s^k-1 t or s^k-1Cs_k-1.last.Cs_k.first→^k-1 t. In the first case, the inductive hypothesis indicates that ^k-1 is irreflexive and so s≠t. In the second case, part (i) of the inductive hypothesis indicates that ^k-1, is transitive, and part (2) of the inductive hypothesis indicates that CS_k.first≯^k-1CS_k-1.last and so s≠t.

(ii) Transitivity: This is immediate from the definition of →^k.

Therefore, →^k is a partial order. The second part of the claim is now illustrated. Suppose Cs_i^kCs_j. This implies that Cs_i.first→^k Cs_j.lasti≠j. There are two cases: either Cs_i.first→^k-1 Cs_j.lasti≠j or Cs_i.first→^k-1 Cs_k-1.last Cs_k.first→^k-1Cs_j.lasti≠j. In the first case, we have Cs_i^k-1Cs_j and so by the inductive hypothesis, i<j. In a similar manner, the second case would give i≦k-1k≦j and so i<j.

In conclusion, the necessary and sufficient condition for finding a controlling computation for B_mutex is that there is no cycle of critical sections with respect to . Further note that, since the proof of Theorem 2 is constructive, it can be used to design a naive algorithm to find a controlling computation.

The following is an explanation of off-line Readers Writers Problem. Let read_critical and write_critical be functions that map a state onto a boolean value. Further, no state can be both read_critical and write_critical (any read and write locked sate is considered to be only write locked). Let critical(s)≡read_critical(s) write_critical(s). The Off-line Readers Writers Problem is a specialization of the Off-line Predicate Control Problem to the following class of global predicates:

B_rw(G)≡&forall;distinct s,t∈G:(write_critical(s) critical(t))

Given a read-critical function and a write-critical function on S and a computation → on S, we define a read critical section and a write critical section in an analogous fashion to the critical sections that were defined before. Note that, since no state is both read_critical and write_critical, critical sections in a process do not overlap.

Let be a relation on both read and write critical sections defined as:

CSCS'≡CS.first→CS'.lastCS≠CS'

Theorem 3 (Necessary Condition) For a computation → of S, and a global predicate B_rw,

	a controlling computation of	=>	all cycles in → contain
	Brw in → exists		only read critical sections

Proof: The proof is similar to the proof of Theorem 1. Providing the contrapositive: Let have a cycle, say CS₁CS₂ . . . Cs_mCS₁. Without loss of generality, let CS₁ be a write critical section. Let →^c be a computation such that →→^c.

First, there is at least one critical section in the cycle say Cs_k (where k≠1), such that CS₁.last≯^cCS_k.first and Cs_k.lasts≯^c CS₁.first. To prove this, assume the opposite:

&forall;Cs_k (k≠1): CS₁.last→^cCs_k .first Cs_k.last→^cCS₁.first--(i)

and prove a contradiction as follows: Cs_mCS₁ implies CS₁.last≯^cCS_m.first. Therefore, by (i), Cs_m.last→^cCS₁.first. This allows the definition of j as the smallest integer such that Cs_j.last→^cCS₁.first. CS₁CS₂ implies that CS₂.last≯^cCS₁.first. Therefore, j≠2. In particular, Cs_j-1 and CS₁ are distinct. By the choice of j, Cs_j-1.last≯^cCS₁.first. So, using (i), CS₁.last→^cCs_j-1.first. We now have a cycle: CS₁.last→^cCS_j-1.first (as above), Cs_j-1.first→^cCs_j.last (since Cs_j-1Cs_j), Cs_j.last→^cCS₁.first (by our choice of j), and CS₁.first→^c CS₁.last (by the definition of first and last) This cycle contradicts the fact that →^c is a partial order.

Since the existence of a Cs_k has been demonstrated such that CS₁.last≯^cCs_k.first and Cs_k.last≯^cCS₁.first, a proof similar to the one in Theorem 1 can be used to show that →^c is not a controlling computation of B_rw in →.

Theorem 4 (Sufficient Condition) For a computation → of S, and a global predicate B_rw,

	all cycles in → contain	=>	a controlling computation of
	only read critical sections		Brw in → exists

Proof: Consider the set of strongly connected components of the set of critical sections with respect to the relation. Define the relation on strongly connected components as SCCSCC'≢∀CS∈SCC,CS'∈SCC':CSCS'SCC≠SCC'. It is verifiable that is a partial order. Therefore, it can be linearized to get a sequence of all strongly connected components, say SCC₁,SCC₂, . . . SCC₁ such that SCC_iSCC_ji<j. Let →^c be defined as (→∪{(Cs_i.last,CS_j.first)|Cs_i∈SCC_k,CS_j∈SCC_k+1 for some 1≦k≦1-1})⁺. Clearly →→^c. It can be shown that →^c is a partial order along similar lines as the proof of Theorem 2.

It is shown that →^c is a controlling computation of B_rw in →. Suppose G is a global state such that B_rw(G). Therefore, states s and t can be found such that write_critical(s) and critical(t). Let CS be a write critical section that contains s and let CS' be a critical section that contains t. Let SCC_i and SCC_j be the strongly connected components that contain CS and CS' respectively. SCC_i is distinct from SCC_j since, otherwise, there would be a cycle in that contains a write critical section. Without loss of generality, let i<j. By the definition of →^c, we have s→^ct and, therefore, →^c-consistent(G). Therefore, →^c is a controlling computation of B_rw in →.

Note, as before, that the proof of Theorem 4 can be used to design an algorithm to find a controlling computation.

The following is an explanation of off-line Independent Mutual Exclusion. Let critical₁, critical₂, . . . critical_m be functions that map an event onto a boolean value. The Off-line Independent Mutual Exclusion Problem is a specialization of the Off-line Predicate Control Problem to the following class of global predicates:

B_ind(G)≢&forall;distinct s, t&forall;∈G:&forall;l:(critical_i(s)critical_i(t))

Given a function critical_i on S and a computation → on S, an i-critical section is defined in an analogous fashion to the critical sections that were defined before. Note that the definition allows independent critical sections on the same process to overlap. In particular the same set of states may correspond to two different critical sections (corresponding to a critical section with multiple locks). Let be a relation on all critical sections defined as before.

Theorem 5 (Necessary Condition)

For a computation → of S, and a global predicate B_ind,

a controlling computation of	=>	→ has no cycles of i-critical
Bind in → exists		sections, for some i

Proof: The proof is almost identical to the proof of Theorem 1.

Theorem 6 (Sufficient Condition) For a computation → of S, and a global predicate B_ind.

→ has no cycles of i-critical	=>	a controlling computation of
sections, for some i		Bind in → exists

Proof: The proof is along similar lines to the proof of Theorem 4. In this case strongly connected components are taken as before, but utilize the fact that no two i-critical sections may be in the same strongly connected component (otherwise, there would be a cycle of i-critical sections).

Using similar definitions, the Off-line Independent Read-Write Mutual Exclusion Problem is a specialization of the Off-line Predicate Control Problem to the following class of global predicates:

B_ind-rw(G)≡&forall;distinct s, t∈G:&forall;i :write-critical_i(s)critical_i(t))

As before, we defined i-read critical sections and i-write critical section (1≦i≦m). Similarly, let → be a relation on all critical selections. The-necessary and sufficient condition is a combination of that of the previous two sections. Since the proofs are similar to the previous ones, we simply state:

Theorem 7 (Necessary and Sufficient Condition)

For a computation → of S_i and a global predicate B_ind-rw,

a controlling computation of	≡	all cycles of i-critical sections in →
Bind-rw in → exists		contain only read critical sections

FIG. 3 shows the algorithm to find a controlling computation of B_ind-rw in →. Since the other forms of mutual exclusion are special cases of B_ind-rw, this algorithm can be applied to any of them.

The input to the algorithm is the computation, represented by n lists of critical sections C₁, . . . , C_n. For now, to simplify presentation, assume that critical sections are totally ordered on each process. Each critical section is represented as its process id, its first and last states, a type identifier cs_id that specifies the critical_cs--id function, and a flag indicating if it is a write or read critical section. The partial order is implicitly maintained by vector clocks associated with the first and last states of each critical section. The algorithm outputs the →ⁿ relation specified as a list of ordered pairs of states.

The first while loop of the algorithm builds ordered, a totally ordered set of strongly connected components of critical sections (called scc's from here on). The second while loop simply uses ordered to construct the →^c relation.

The goal of each iteration of the first loop is to add an scc, which is minimal w.r.t. →, to ordered (where → is the relation on scc's defined in the proof of Theorem 4). To determine this scc, it first computes the set of scc's among the leading critical sections in C₁, . . . C_n. Since no scc can contain two critical sections from the same process, it is sufficient to consider only the leading critical sections. From the set of scc's, it determines the set of minimal scc's, crossable. In then randomly selects one of the minimal scc's. Finally, before adding the scc to ordered, it must check if the scc is not_valid, where not_valid(crossed)≡∀cs₁cs¹∈crossed:cs.cs^--id . . . cs₁.cs_idcs.write_critical. If an invalid scc is found, no controlling computation exists (by Theorem 7).

The main while loop of the algorithm executes p times in the worst case, where p is the number of critical sections in the computation. Each iteration takes O(n²) since it must compute the scc's. Thus, a simple implementation of the algorithm will have a time complexity of O(n²p). A better implementation of the algorithm, however, would amortize the cost of computing scc's over multiple iterations of the loop. Each iteration would compare each of the critical sections that have newly reached the heads of the lists with the existing scc's, thus forming new scc's. Each of the p critical section, therefore, reaches the head of the list just once, when it is compared with n-1 critical sections to determine the new scc's. The time complexity of the algorithm with this improved implementation is, therefore, O(np). Note that a naive algorithm based directly on the constructive proof of the sufficient condition in Theorem 7 would take O(p²). The complexity has been significantly reduced by using the fact that the critical sections in a process are totally ordered.

The algorithm has implicitly assumed a total ordering of critical sections in each process. As noted before, however, independent critical sections on the same process may overlap, and may even coincide exactly (a critical section with multiple locks is treated as multiple critical sections that completely overlap). The algorithm can be extended to handle such cases by first determining the scc's within a process. These scc's correspond to maximal sets of overlapping critical sections. The input to the algorithm would consist of n lists of such process-local scc's. The remainder of the algorithm remains unchanged.

Referring to FIG. 4, in its application to software fault tolerance, the present invention consists of four parts: (A) tracing an execution, (B) detecting a synchronization failure, (C) determining a control strategy, and (D) re-executing under control.

After determining a control strategy the algorithm used in the present invention determines which synchronizations to add in order to avoid very general forms of mutual exclusion violation. As mentioned before, the other three parts of our scheme have been addressed as independent problems. All of the pieces are at this point put together for a comprehensive look at how race failures (mutual exclusion violations) can be tolerated.

FIG. 5 illustrates an example of tolerating races in a concurrent execution. The problem of determining a control strategy was placed in a very general model of concurrent execution. Tracing, detection, and controlled re-execution, however, depend greatly on the particular concurrent paradigm. A simple example is best chosen to demonstrate the key issues that will arise in most concurrent paradigms.

Consider a distributed system of processes that write to a single shared file. The file system itself does not synchronize accesses and so the processes are responsible for synchronizing their accesses to the file. If they do not do so, the writes may interleave and the data may be corrupted. Since the file data is very crucial, it must be ensured that races can be tolerated.

Synchronization occurs through the use of explicit message passing between the processes. The first part of our mechanism involves tracing the execution. The concern during tracing is to reduce the space and time overhead, so that tolerating a possible fault does not come at too great a cost. In the example, a vector clock mechanism is used, updating the vector clock at each send and receive point. This vector clock needs to be logged for each of the writes to the file (for the algorithm of the present invention). The vector clock values must also be logged for each receive point (for replay purposes). When a write is initiated, and when it returns, the vector clock must be logged. In the example, the writes are typically very long and therefore are performed asynchronously. Thus, execution continues while the write is in progress. In particular, the process may receive a message from another process during its write to the file. Inserting some computation at the send, receive, write initiation, and write completion points can be achieved either by code instrumentation, or by modifying the run-time environment (message-passing interface and the file system interface).

The second part of our mechanism is detecting when a race occurs. Since message passing is used as the synchronization mechanism, the methods described in a Ph.D. thesis by R. H. B. Netzer, entitled "Race condition detection for debugging shared-memory parallel programs," University of Wisconsin-Madison, 1991, are particularly applicable. Once a race has been detected, all processes are rolled back to a consistent global state prior to the race. The file is also rolled back to a version consistent with the rolled-back state of the processes. (A versioned file system with the ability to roll back must be assumed.) The section of the traced vector clock values that occur after the rolled-back state is then noted. The section indicates the critical section entry and exit points required by the algorithm. The algorithm would take O(np) time, where n is the number of processes and p is the number of critical sections that have been rolled back. The output of the algorithm is the set of added synchronizations specified as pairs of critical section boundary points.

FIG. 5 demonstrates a possible scenario. Here the semantics of mutual exclusion correspond to a single exclusive lock. Therefore, the necessary and sufficient condition is that there are no cycles in the critical section graph shown in FIG. 4(b) Applying the algorithm would add synchronizations to give the controlling computation shown in FIG. 5(c).

The next step is to replay the processes using the logged vector clock values of the receive points. Each receive point must be blocked until the same message arrives as in the previous execution. This is a standard replay mechanism. In addition in this replay, additional synchronizations must be imposed. For example, suppose (s, t) in one of the synchronizations output by our algorithm. The state s is a critical section exit point while t is a critical section entry point. Each of these additional synchronizations is implemented by a control message sent from s and received before t. Thus, at each critical section exit point, the added synchronizations must be checked to decide if a control message must be sent. At each critical section entry point, the added synchronizations must be checked to decide if the process must block waiting for a control message. As in tracing, the points at which computation must be added are the write initiation and completion points, and the send and receive points. Again, this can be accomplished by code instrumentation or run-time environment modification.

An example has been chosen in which the processes only write to the file. If the processes were to read from the file as well, then that would cause causal dependencies between processes. Then these causal dependencies would have to be tracked as in the tracking for the messages. Another option would be to assume that these causal dependencies do not affect the message communications, in which case, they do not need to be tracked. However, if this approach is taken, it would have to be checked out to determine that the traced computation is the same as the one being replayed. In case of a divergence, the execution would be left to proceed uncontrolled from the point of divergence.

Whereas the invention has been described with respect to specific embodiments thereof, it will be understood that various changes and modifications will be suggested to one skilled in the art and it is intended to encompass such changes and modifications as fall within the scope of the appended claims.

Claims

1. A method of providing fault tolerance in concurrently executing computer programs by controlling the re-execution of concurrent programs in order to avoid a recurrence of synchronization failures, comprising:

(a) tracing the execution of concurrent programs to provide tracing information;

(b) detecting synchronization failures resulting from said execution of the concurrent programs; and

(c) applying a control strategy, based on said detection of failures, for a re-execution of the concurrent programs said control strategy using the tracing information to add synchronizations during said re-execution, said re-execution of said concurrent programs being based on an automatically formulated computer operation that is derived from information traced during a failed execution.

2. The method of claim 1 wherein said application of a control strategy includes causing a re-execution of said concurrent programs under a control derived from tracing information during an execution, and wherein said control includes using said information to add synchronizations to said concurrent programs during re-execution.

3. The method of claim 2 wherein said control strategy is applied by tracing information during an initial concurrent program execution and using this information to add synchronizations during subsequent re-execution of said concurrent programs.

4. The method of claim 1 wherein said strategy is automatically formulated within a computer system by providing concurrent program failure input to a computer-based algorithm, wherein critical sections of concurrent programs are identified and ordered for each process, each critical section being represented by a process id, its first and last states, a type identifier specifies the critical function, and a flag indicating if it is a write or read critical section.

5. The method of claim 4, wherein a first loop of the algorithm builds a ordered set of strongly connected components of critical sections and a second loop utilizes the ordered set to construct a relationship with concurrent program execution.

6. A method for fault tolerance in concurrently executed software programs, comprising:

tracing executions of concurrent programs to identify faults and to provide tracing information;

identifying faults in the execution of said concurrent programs; and

using controlled re-execution of said concurrent programs based on the identification of faults, said tracing information being used to add synchronizations during the re-execution, and said re-execution of said concurrent programs being based on an automatically formulated computer operation that is derived from said tracing information.

7. The method of claim 6, wherein said controlled re-execution is achieved by tracing information during an initial execution of said concurrent programs.

8. The method of claim 6 wherein said re-execution of said concurrent programs is based on an automatically formulated strategy that is based on information traced during a failed execution.

9. The method of claim 8 wherein said strategy is automatically formulated within a computer by providing concurrent program failure input to a computer-based algorithm, wherein critical sections of concurrent programs are identified and ordered for each process, each critical section being represented by a process id, its first and last states, a type identifier specifies the critical function, and a flag indicating if it is a write or read critical section, and wherein a first analysis by said algorithm builds a ordered set of strongly connected components of critical sections and a second analysis of said algorithm utilizes the ordered set to construct a relationship with concurrent program execution, said first and second analysis resulting in identification of critical section of said concurrent programs requiring assistance.

10. The method of claim 9 wherein said assistance comprises the addition of synchronizations to critical sections of said concurrent programs.

11. A Method of correcting synchronization faults occurring during the execution of concurrent programs, comprising:

tracing the execution of concurrent programs;

detecting a synchronization error within the execution of said concurrent programs;

resetting program processes and associated programs files to a consistent global state prior to said error;

recording a section of the traced vector clock values that occur after the rolled-back state, wherein said section indicates the critical section entry and exit points required by the algorithm and further indicates failure points within execution of said concurrent programs;

adding synchronizations specified as pairs of critical section boundary points to identified failures within said sections;

replaying said concurrent programs using the logged vector clock values of the receive points, wherein each receive point must be blocked until the same message arrives as in the previous execution; and

using each of said added synchronizations during said replaying of said concurrent programs to ensure that execution of a critical section of one of said concurrent programs is completed before execution of a critical section of another of said concurrent programs commences.

12. The method of claim 11 wherein additional synchronizations are imposed as needed until successful execution of said concurrent programs is accomplished.

13. A method of providing tolerance to synchronization faults during concurrent execution of computer program components, one of said concurrent program components having a first critical section and another of said concurrent program components having a second critical section, said method comprising the steps of:

tracing the execution of concurrent program components to acquire tracing information pertaining thereto, including information pertaining to a synchronization failure resulting from said execution of said concurrent program components;

using said tracing information to derive one or more synchronizations for use in selectively controlling a re-execution of said concurrent program components; and

re-executing said concurrent program components with said derived synchronizations being added to said re-execution, a particular one of said derived synchronizations being operative to ensure that execution of said first critical section is completed before execution of said second critical section commences.

14. The method of claim 12 wherein:

one of said derived synchronizations is implemented by a control message sent from an exit point of said first critical section, and received before an entry point of said second critical section.