15
T T T Ta a a ab b b b lll le e e e 1111....1111:::: TTTTyyyyppppeeeessss ooooffff ccccoooonnnnccccuuuurrrrrrrreeeennnnccccyyyy ccccoooonnnnttttrrrroooollll,,,, wwwwiiiitttthhhh eeeexxxxeeeemmmmppppllllaaaarrrryyyy ssssyyyysssstttteeeemmmmssss....
Table 1.1 shows possible answers to this question as the result of interaction along two
distinct axes, creating a simple taxonomy of application concurrency models. One axis is his-
tory structure, the relationships between application operations’ resultant states, and the
other is the types of divergence supportable within a given type of history structure. Each
cell of the table contains the name of a previously described system that exemplifies that
kind of model. They can be more fully described as follows:
• Single states.This kind of system always has a well known “current” state for any shared
object, and that single state is always accessible. In a convergent single state system the
state is always fully consistent from the application perspective, in a divergent single
state system, some inconsistencies are permitted in the application state. Most operating
systems provide the convergent version of this as the basic file system abstraction. HTTP
1.1, when used with the PUT method, and without any extensions, implements the di-
vergent version of this, since the lack of locking allows changes to be inadvertently
overwritten. Prospero also implements divergent single-state editing, but guarantees
eventual convergence with some attempt to preserve editing intentions.
• Multiple sequential states.This kind of system presents a linear history of significant
states, ordered temporally. In convergent systems, this history always corresponds to a
serial execution history. Augment (Engelbart, Watson et al. 1973; Engelbart 1984)used a
model like this. In a divergent system, the serial order assumption would not be true,
and some changes might be lost in subsequent updates.
• Multiple branching states.This model is the one that has been adopted as the basis for
most software engineering systems (Rochkind 1975; Tichy 1985). Many states corre-
sponding to different possible execution histories exist in parallel. While a pessimistic
variant of such a system is possible, it makes little sense, as any conflict can be resolved,
serial ordering preserved, and no changes lost: simply by creating a new branch when-
T T T Ta a a ab b b b lll le e e e 1111....1111:::: TTTTyyyyppppeeeessss ooooffff ccccoooonnnnccccuuuurrrrrrrreeeennnnccccyyyy ccccoooonnnnttttrrrroooollll,,,, wwwwiiiitttthhhh eeeexxxxeeeemmmmppppllllaaaarrrryyyy ssssyyyysssstttteeeemmmmssss....
Table 1.1 shows possible answers to this question as the result of interaction along two
distinct axes, creating a simple taxonomy of application concurrency models. One axis is his-
tory structure, the relationships between application operations’ resultant states, and the
other is the types of divergence supportable within a given type of history structure. Each
cell of the table contains the name of a previously described system that exemplifies that
kind of model. They can be more fully described as follows:
• Single states.This kind of system always has a well known “current” state for any shared
object, and that single state is always accessible. In a convergent single state system the
state is always fully consistent from the application perspective, in a divergent single
state system, some inconsistencies are permitted in the application state. Most operating
systems provide the convergent version of this as the basic file system abstraction. HTTP
1.1, when used with the PUT method, and without any extensions, implements the di-
vergent version of this, since the lack of locking allows changes to be inadvertently
overwritten. Prospero also implements divergent single-state editing, but guarantees
eventual convergence with some attempt to preserve editing intentions.
• Multiple sequential states.This kind of system presents a linear history of significant
states, ordered temporally. In convergent systems, this history always corresponds to a
serial execution history. Augment (Engelbart, Watson et al. 1973; Engelbart 1984)used a
model like this. In a divergent system, the serial order assumption would not be true,
and some changes might be lost in subsequent updates.
• Multiple branching states.This model is the one that has been adopted as the basis for
most software engineering systems (Rochkind 1975; Tichy 1985). Many states corre-
sponding to different possible execution histories exist in parallel. While a pessimistic
variant of such a system is possible, it makes little sense, as any conflict can be resolved,
serial ordering preserved, and no changes lost: simply by creating a new branch when-
