Analysis of Optimistic Concurrency Control Revisited
Theodore Johnson
September 3, 1992
Abstract
Ryu and Thomasian have analyzed several varieties of optimistic concurrency control under two
assumptions: that the characteristics of a transaction remain constant throughout its execution, and
that the proportion of committing transactions is fixed (in order to avoid an unrealistic biasing of
the transaction mixture). We show how both of these assumptions can be relaxed. First, we allow
an aborted transaction to resample its execution time from the distribution that describes the trans
action class execution times. Second, we allow transactions to change their class if they are aborted.
These assumptions are more appropriate for analyzing special applications of optimistic concurrency
control, such as nonblocking data structures and realtime optimistic transaction processing. We
use our analyses to show that OCC performance has different characteristics in the new transaction
models, and to analyze a simple nonblocking queue algorithm.
1 Introduction
Many types of database concurrency control have been proposed, including static locking, twophase
locking, certification, multiversion concurrency control, and optimistic concurrency control [2]. In this
paper, we analyze optimistic concurrency control (OCC) [14]. Optimistic concurrency control is so
named because it makes the optimistic assumption that data conflicts are rare. A transaction accesses
data without regard to possible conflicts. If a data conflict does occur, the transaction is aborted and
restarted.
Menasce and Nakanishi [17] present a Markov chain model of OCC in which aborted transactions
leave, then reenter the transaction processing system as new transactions. Morris and Wong [18, 19] note
that generating new transactions to replace aborted ones biases the transaction processing system towards
executing short fast transactions. These authors provide an alternative solution method that avoids the
bias by requiring that the transaction that replaces the aborted transaction be identical to the aborted
transaction. Ryu and Thomasian [24] extend this model of OCC to permit a wide variety of execution
time distributions and a variety of OCC execution models. Yu et al. [32, 31] develop approximate models
of OCC and locking concurrency control to evaluate their performance in transaction processing systems.
read(g,Ta)
read g into T's local workspace
access_time(g)=Global_time
validate(T)
for each g E R(T)
if access_time(g)
abort(T)
for every g E W(T)
t(g)=Global_time
commit(T)
Figure 1: OCC validation
In this paper, we extend the simple but flexible model of Ryu and Thomasian [24] to handle additional
transaction processing models. We modify the transaction model to examine the bias towards fast
transactions that OCC introduces (taking the transaction execution model to that in [17]). We developed
these OCC models as a tool for analyzing the performance of nonblocking data structure algorithms
[20, 21, 29, 30], and they also have applications in analyzing real time optimistic transaction processing
schemes [6, 9].
2 Model Description
Data access conflicts in OCC are detected by the use of timestamps. Each data granule, g, (the smallest
unit of concurrency control) has an associated timestamp, t(g), which contains the last time that the
data granule was written to. Each transaction, T, keeps track of its read set R(T) and write set W(T).
We assume that R(T) D W(T). Every time a new data granule is accessed, the time of access is recorded.
If at the commit point a data granule has a last write time greater than the access time, the transaction
is aborted. Otherwise, the transaction is committed and the last write time of each granule in W(T) is
set to the current time. The procedure used is shown in figure 1.
Following Ryu and Thomasian, we distinguish between static and dynamic concurrency control. In
static concurrency control, all data items that will be accessed are read when the transaction starts. In
dynamic concurrency control, data items are read as they are needed. We also distinguish between silent
and broadcast concurrency control. The pseudocode in Figure 1 is silent optimistic concurrency control:
an operation doesn't advertise its commit, and transactions that will abort continue to execute. Alter
natively, a transaction can broadcast its commit, so that conflicting transactions can restart immediately
[22, 5].
We model the transaction processing system as a closed system in which V transactions each execute
one of C transaction types. When a new transaction enters the system, it is a class c transaction with
probability fc, _c fc = 1. A class c transaction is assumed to have an execution time of 3(V)bc(x), where
3(V) is the increase in execution time due to resource contention. Factoring out 3(V) is an example of
a resource contention decomposition approximation [26, 24, 10], which lets us focus on the concurrency
control mechanism, and which allows the analysis to be applied to different computer models. We will
assume that /(V) = 1 in the analysis. Expansions in execution time can be factored back in after
performing the concurrency control analysis.
As a transaction T executes, other transactions will commit their executions. If a committing trans
action conflicts with T, then T must be aborted. We denote by E(k, c) the probability that a committing
class k transaction conflicts with an executing class c transaction. We model the stochastic process in
which committing transactions conflict with an executing transaction as a Poisson process. Ryu and
Thomasian [24] show that this assumption, which makes the analysis tractable, leads to accurate model
predictions under a wide variety of conditions.
We differentiate between three models depending on the actions that occur when a transaction aborts.
In [24], a transaction samples its execution time when it first enters the system. If the transaction is
aborted, it is executed again with the same execution time as the first execution time. We call this
transaction model the fixed time/fixed class model, or the FF model1. The FF model avoids a bias for
fast transactions, permitting a fair comparison to lockbased concurrency control.
The variability of the execution time of a transaction could be due to resource contention, to decisions
the transaction makes when as it accesses the database., or a combination of both. In these cases, the
execution time of a transaction changes when a transaction is reexecuted after an abort. We introduce
the variable time/fixed class, or VF, model to represent this situation. In the VF model, an aborted
transaction chooses a new execution time for its next execution.
There are some situations in which an aborted transaction simply exits the system and is not re
executed (for example, the transactions might be sensor data reports in a real time data monitoring
'Most of the results that we present for the FF model have been taken from [24].
system). In the variable time/variable class, or VV model, a new transaction type is picked to replace
an aborted transaction (possibly a transaction of the same type).
2.1 Model Solution Methods
For a given transaction model, we can solve the system for any of the OCC models in the same way.
The method for solving the system depends on the transaction model: the FF and the VF models use
the same method, but the VV model is solved by using a different method.
2.1.1 Solving the FF and VF Models
The solution method for the FF and VF models involves taking the system utilization U (the portion of
time spent doing useful work) and finding the perclass utilizations Uc. The system utilization U is then
computed from the perclass utilizations. Ryu and Thomasian show that the equations can be solved
quickly through iteration.
The mean useful residence time of a class c transaction is denoted by R'(V). A transaction might
be required to restart several times due to data conflicts. The expected time that a transaction spends
executing aborted attempts is denoted by Rd(V), and the total residence time of a class c transaction
is Re(V) = R'(V) + Rj(V). The utilization of a class is the proportion of its expected residence time
spent in an execution that commits: Uc = R i(V)/(R'(V) + Rid(V)). The expected residence time a
transaction in the system is calculated by taking the expectation of the perclass expected residence
times. The system efficiency is calculated by
U(V)=Ra(V)/1[ fR(V)/U(V) (1)Y
c=l 1
In order to calculate the perclass efficiencies, we need to calculate the probability that a transaction
aborts due to a data conflict. We define ((k, c) to be the probability that a class k transaction conflicts
with a class c transaction. We know the proportions of committing transactions, so we can calculate the
probability that a committing transaction conflicts with a class c transaction <1c by:
C
1 = 1(k, c)f (2)
k=l
We can calculate the rate at which a committing transactions conflict with a class c transaction, 7, by
setting 7, to be the proportion of committing transactions that conflict with a class c transaction:
(V 1)4,
S= U(V)
where b is the expected execution time of all transactions.
Given the system utilization, we can calculate the perclass conflict rate. From the perclass conflict
rate, we can calculate the perclass utilizations, and from the perclass utilizations, we can calculate the
system utilization. The output system utilization is a decreasing function of the input system utilization.
In the FF model, the utilization is bounded by 1, so the unique root in [0..1] can be found using a binary
search iteration. In the VF model, it is possible for the utilization to be greater than 1, so the root finder
must use one of the standard nonlinear equation solution methods [1].
2.1.2 Solving The VV Model
In the VV transaction model, when a transaction aborts, it leaves the system and a new transaction
enters. As a result, the proportion of committing class c transactions is no longer f, and instead depends
on the probability that a class c transaction commits, pc, and the average execution time of a class c
transaction. The solution method for the VV model is based on iteratively finding a root for the vector
P.
In order to calculate the conflict rate, we need to know the proportion of transactions Sk that are
executing a class k transaction. When a process is executing a class k transaction, it executes for an
expected bk seconds. If one was to observe a very large number of transaction executions, say M, then
a class k transaction would be executed about Mfk times. Thus, the observation period would take
_i=1 Mfibi seconds, during which a class k transaction would be executed for Mfkbk seconds. By the
theory of alternating renewal processes [23], we have
C
Sk =fkbk/ fibi (3)
i=1
If process is executing a class k transaction, it will finish at rate 1/bk. When the transaction completes,
it will commit at rate pk, and if it commits, it will conflict with a class c transaction with probability
NI(k, c). Therefore,
7c = (V 1) 1Skpk(k, c)bk
(V 1) EC (fkbk 1 fib)pk(k, c)/bk
ViL 1 1(k, c)fkk (4)
Given the probability that transactions of each transaction class commits, p', we can calculate conflict
rate 7c for each transaction class. Given the conflict rate for a transaction class 7c, we can calculate the
probability that the transaction will commit pc.
Unlike the case with the FF and the VF models, for the VV model, we need to iterate on a vector.
We make use of a property of the system of equations to find a rapidly converging iterative solution: if
F is the transformation F(fold) = new, then F(p, ...,pc + C, .. .,Pc) < F(pl,..., p, ... ,pc), where
c > 0 and the vector relation < refers to componentwise comparison. In other words, the Jacobian of F
is strictly nonpositive. The algorithm that we use to find a solution of the VV calculates the ith value of
Pc to be p = (pi F(ic)/2.
3 Analysis
In this section, we present the calculations needed for solve the systems discussed in the previous section.
For each of the four types of optimistic concurrency control, we present the calculation for each of the
three transaction models.
3.1 Analysis of Silent/Static OCC
In this section, we examine the simplest OCC scheme. In the silent/static scheme, transactions access
their entire data sets when they start their executions, and detect conflicts when they attempt to commit.
3.1.1 Fixed Time/Fixed Class
In [24], if a transaction executes for t seconds, then aborts, it will execute for t seconds when it restarts.
If an operation requires t seconds, the probability that it will be commit is e7', since we assume that
conflicts form a Poisson process. Therefore, the number of times that a class c transaction with running
time t must execute has the distribution
Pc(kit) = (1 eCct)kl 7't
and has mean e6t. A class c transaction with running time t therefore has a mean residence time of
teOt, and class c transactions have a running time of
RC(V)= f0 tec'bc(t)dt
where BS is the first derivative of the Laplace transform of bc(t) [13]. Finally, the perclass utilization
can be calculated for the iteration to be
Uc= R(V)/R(V) (5)
= b/ ( ) (6)
We note that bc(t) must be o(tle1c') for the integral to converge.
3.1.2 Variable time / Fixed Class
In the variable time/fixed class model, every time a class c transaction executes its running time is
sampled from bc(t). Therefore, the unconditional probability that the operation commits is:
Pc= fto etbc(t)dt (7)
Bc (7c) (8)
The number of times that the operation executes has a geometric distribution, so an operation will
execute 1/pc times. The first 1/pc 1 times the operation executes, it will be unsuccessful. Knowing
that the operation is unsuccessful tells us that it probably required somewhat longer than average to
execute, since slow operations are more likely to be aborted. Similarly, successful operations are likely
to be faster. In particular, an operation will be successful only if it reaches its commit point before a
conflict occurs, and will be unsuccessful only if a conflict occurs before it reaches its commit point. The
distributions of the execution times of the successful and unsuccessful operations is given by taking order
statistics [3]:
b"(t) = K,etbc(t) (9)
b (t) = Kf (le c )bc(t) (10)
where K, and Ki are normalizing constants computed by
K, = e ctb(t)dt
oKf (f tbC(t)dt
\n
If b' and b( are the expected values of b (t) and b (t), respectively, then the expected time to complete
a class c operation is
Re(V) = b + (l/p, 1)b (11)
= bl + p (1 pe)bi (12)
We observe that we only need to calculate b", because
b, = pb +(1 p,)b( (13)
so that by combining (11) and (13) we get:
Re(V) = bc/ (14)
Therefore, we find that
U= R (V)/Re(V)
Pc (15)
We note that in the variable time model, the only restriction on the distributions bc(t) is that they
have finite means.
3.1.3 Variablespeed Model
For the silent/static VV model, we calculate the conflict rate from formula (4) and the probability that
a class c transaction commits from formula (8).
3.2 Analysis of Static/Broadcast OCC
In static/broadcast OCC, transactions access their entire data sets when they start execution, and abort
whenever a conflicting transaction commits.
3.2.1 Fixed/Fixed
The probability that a transaction restarts is calculated in the same way as in the silent/static model,
given the same conflict rate. The wasted time per transaction now has a truncated exponential distri
bution:
1 eTt
As a result,
Uc(V) (16)
1 B)(7c)
3.2.2 Variable/Fixed
The probability that a transaction commits, pc, and the expected execution time of transactions that
commit b' are calculated in the same way as in the silent/static model. The execution time of the aborted
transactions is different, since a transaction will abort after t if some other transaction conflicts with it
t seconds after it starts, and it has not yet committed:
b{(t) = K [ce7t(1 B(t))]
where
17c f, eic S bc(T)dTdt
1 1
1wB,(7,)
Since a conflict aborts a transaction early, we can not make use of equation (13) to simplify equa
tion (11). Instead, we must actually calculate the expected values b' and b4:
b = (l/p) fo teYb,(t)dt
B (7c)/Pc (17)
b = K ftSo 7cte 't(1 Bt(t))dt
1 (1/7c 7c to (d7t j ()drdt)
1 1_ ) (i/7c7 Dc ( c($)/$s ))
1 ) (l/D + 8 7) c7 /7)
1+2 lcB(7c) Bc(7) (18)
;7c(1_B (7c)) (
Putting these formulae into equation (11) for R,(V), we find that
R6(V) 1 13,(7,) (19)
and,
Uc(V) b1,( ) (20)
We note that if bc(t) has an exponential distribution, then Uc = 1. This relation can be used to directly
solve a system where all execution times are exponentially distributed, or to simplify the calculations
when some execution time distributions are exponentially distributed and some are not.
3.2.3 Variable/Variable
In the silent/static case, a class k transaction executes for an expected bk seconds. In the broadcast/static
case, a transaction terminates early if it is aborted. The average amount of time that a transaction spends
executing a class k transaction, bk, is the weighted average of the execution time depending on whether
or not the transaction commits. By using equations (17) and (18), we find that:
bk = + ( pk)b
= (1 (7k))/7k (21)
Therefore, the proportion of time that a process spends executing a class k transaction is
C
Sk = fkbk/ fibi (22)
i=l
and the conflict rate of a class c transaction is
7c= b (c,k)fkpk (23)
k=l
where b = F 1 fibi. Given a conflict rate 7, we calculate pc by using equation (8).
3.3 Analysis of Silent/Dynamic
In dynamic optimistic concurrency control, a transaction accesses data items as they are needed. A class
c transaction that requests n, data items has n, + 1 phases. As the transaction accesses more data items,
it acquires a higher conflict rate. We redefine the conflict function 4 to model the different phases of
the transactions. If a class k transaction commits, it conflicts with a class c transaction in stage i with
probability 1(k, c, i). The probability that a committing transaction conflicts with a class c transaction
in stage i is:
C
c,i = fk(k, c, i) (24)
k=l
The conflict rate for a class c transaction in stage i is:
(V, = 1 U(V) (25)
The amount of time that a class c transaction spends in stage i has the distribution bei(t) with mean
b,,i, and the average time to execute the transaction is b, = c b,i.
3.3.1 Fixed/Fixed
As a transaction moves through different stages, it encounters different conflict rates. The conflict rate
for a class c transaction is a vector:
c = (7,1, 7, c,nc+1)
Similarly, the execution time of a class c transaction is a vector i = (xi, X2,..., xc+l), where xi is a
sample from the distribution with density b,i(x). The probability that a class c transaction aborts is
therefore
Pc = 1e Cz
By taking expectations over the times for the processing stages, Ryu and Thomasian find that
R(V) (r c j C
i=0 i= 0 c,i)
3.3.2 Variable/Fixed
We use the same transaction model as in the Fixed/Fixed case. A transaction will commit only it
completes every stage without conflict. We define p,,i to be the probability that a class c transaction
completes the ith stage without a conflict. We can calculate pci by using formula (8), and substituting
Bc,i for B and 7,i for 7c. Given the p,,i, we can calculate pc by
rnc+l
Pc = 1= Pc,i
f= l 1 ci(Dc.,i) (26)
As in the case of silent/static concurrency control, the unconditional expected time spent executing
a class c transaction is be, so that
Uc = pc (27)
3.3.3 Variable/Variable
For the VV model, we use formula (4), appropriately modified to calculate the conflict rates, and for
mula (26) to calculate pc.
3.4 Dynamic/Broadcast
3.4.1 Fixed/Fixed
The analysis of dynamic/broadcast concurrency control under the fixed/fixed model uses a combination
of the previously discussed techniques. Ryu and Thomasian show that
Re = R%, + Rd2
R, = S(0) E=o [k ( k 8c(7c)) (1 8c(7c,))]
R (V) = =o [k (Hf c7 c)k (8c(7c,kc) 1 7c,kbc)
3.4.2 Variable/Fixed
We can use formula (26) to calculate pe. For each processing phase, we can use formulae (17) and (18)
to calculate b',i and bJi. If a transaction commits, then it successfully completed each phase, so that
nc+l
b' = b (28)
i=0
If a transaction fails to commit, then it might have failed at any one of the nc + 1 stages. We
define qc = 1 pc to be the probability that a transaction aborts, and qc,i to be the probability that
a transaction aborts at stage i, given that it aborts. A transaction that aborts at stage i must have
successfully completed the previous i 1 stages, and a transaction aborts at exactly one of the stages, so
i1
ci Pci
S= q Pc,
'j=1
If a transaction aborts at stage i, then its expected execution time is:
i1
b+ bS
j=1
Therefore, b( is the unconditional expected execution time:
nc+l i1 i1
b = (1 p,) P, b + b, (29)
i=1 j=1 j=1
We then use formulae (28) and (29) in formula (11) to find Re(V).
3.4.3 Variable/Variable
We use formula (26) to calculate pc, and formulae (28) and (29) in formulae (21) and (23) to calculate
the conflict rate.
4 Model Validation and Experiments
We wrote an OCC simulator to validate our analytical models. A parameterized number of transactions
executed concurrently, and committing transactions conflicted with other transactions depending on a
sample from 1. We ran the simulation for 10,000 transaction executions, then reported statistics on
throughput, execution time, and commit probabilities.
Ryu and Thomasian have already validated the F/F model, so we present a validation only of the V/F
and V/V models (we also simulated the F/F model, and found close agreement between the simulation
and analysis). In our first validation study, we modeled a system with a single transaction type. If there
is only one transaction type, the V/F and the V/V models are the same, so we present results for the
V/F model only (we also ran simulations and analytical calculations for the V/V model, and obtained
nearly identical results). We calculated 4I by assuming that the transactions randomly accessed data
items from a database that contained N = 1024 data items, and that transactions with overlapping data
sets conflict. Ryu and Thomasian provide the following formula for the probability that two access sets
of size n and m overlap in a database with N data items:
(n,mN) 1 (Nm n/(
We report the probability that a transaction commits for a variety of access set sizes and degrees of
concurrency in Table 1. The execution times in the static concurrency control experiments and the phase
V Static/'1I. i Static/Broadcast
access set size 4 16 32 4 16 32
5 sim .9391 .6418 I., .9378 .5270 ' I
ana .9444 '...i.i. .4586 .9414 .5272 .2797
15 sim .8399 .4249 '.., .8113 .2439 '; II
ana .8446 .4272 .2822 .8212 .2416 .0999
25 sim .7716 .3474 .2152 .7201 .1569 .0614
ana .7 '.. .3481 .2241 .7281 !'.7 .0608
Dynamic/'l ,. iI Dynamic/Broadcast
5 sim .9700 .7020 .4404 .9686 .6811 .3937
ana .9704 .7189 .4879 .9700 i.' II. .4325
15 sim *", .4587 .2627 .9039 .4187 .1971
ana .9071 .4733 .2627 l' .3071 .1319
25 sim .8481 ..s .1645 ItN .2988 .1156
ana ."I .3703 .1910 171' .3071 .1319
Table 1: Validation study of the V/F model. pc is reported for a single transaction class and exponentially
distributed execution times.
V Varying/Fixed Varying/Varying
analytical simulation analytical simulation
class 1 class 2 class 1 class 2 class 1 class 2 class 1 class 2
5 .9692 \', .9684 .8941 .9692 .8946 .9672 *'';
15 .9069 .7081 .9069 .71N .9066 .7073 .9009 .6919
25 "' .5864 .. ..', ; .4 .5828 .8511 .'>
35 .8203 .5011 .8167 .4906 .8168 n.. .8014 .4660
45 .7884 .4379 .7". .4282 .7822 I... .71.7 .3986
55 .7 '.1 .3812 .7612 .3892 .7521 .3736 .7"' .3 '.
Table 2: Validation study for Dynamic/Broadcast OCC and two transaction classes. pc is reported.
Execution phase times are exponentially distributed.
execution times in the dynamic concurrency control experiments were exponentially distributed. The
experiments show close agreement between analytical and simulation results, though the calculations are
least accurate for the dynamic concurrency control when the level of conflict is high.
We also performed a validation study for a system with two transaction classes. The first transaction
class accesses four data items, and the second accesses eight data items. To save space, we reports results
for dynamic/broadcast OCC only. Table 2 reports simulation and analytical results for the V/F and
the V/V transaction models for a variety of degrees of concurrency. In these experiments, fi = .6 and
f2 = .4. We found close agreement between the simulation and the analytical predictions.
SS SB DS DB
V FF VF FF VF FF VF FF VF
5 4.012 4.102 4.420 4.529 4.425 4.482 4.593 4.653
10 6.621 6.899 7.780 8.168 7.829 8.036 8.379 8.610
15 8.582 9.075 10. 1'i 11.223 10.604 11.016 11.596 12.074
20 10.163 111 . 12.728 13.864 *1'.; 13.603 14.391 15.150
25 11.482 12.419 14.651 16.196 15.002 15.894 16.861 17.937
30 12.637 13.778 16.329 1. '. 16.811 17 *"*. 19.072 20.484
Table 3: Comparison of OCC performance, Erlang distribution. Throughput is reported
4.1 Comparison of OCC Schemes
We ran a set of experiments to determine the effect of the different OCC schemes on system performance.
In table 3, we compare the performance of SS, SB, DS, and DB OCC for the FF and the VF transaction
models. The transaction processing system contains a single transaction class, which accesses 8 data
items in a database of 1024 data items. The total execution time for all experiments has an Erlang
distribution with mean 1.0.
We find the surprising result that SB concurrency control gives better performance than DS concur
rency control in the VF transaction model. The FF transaction model give the opposite result. For the
VF model, SS < DS < SB < DB, while in the FF model, SS < SB < DS < DB. We also find that a trans
action processing system with VF transactions has a higher throughput than a transaction processing
system with FF transactions (though the transaction model is typically fixed by the application).
We also ran experiments for SS and SB concurrency control in which the transaction execution times
are exponentially distributed. These results are listed in table 4. We found that while the performance
of the FF transactions decreased with the increase in execution time variance, the performance of the VF
transactions increased. The performance of the SB OCC on the VF transactions became significantly
greater, surpassing the performance of the DB OCC.
5 An Application: Nonblocking Data Structures
Many parallel data structures use locks to ensure simultaneous but noninterfering access. Other parallel
data structures avoid the use of locks [16, 20, 21, 15, 7, 8, 25, 27, 4, 28, 29, 30]. Nonblocking data
structures avoid the use of locks, and also guarantee that no operation blocks the execution of any
other operation for more than a finite number of steps [7]. Nonblocking data structures are tolerant of
SS SB
V FF VF FF VF
5 3.456 4.157 4.019 5.000
10 5.146 7.174 6.455 10.000
15 6.237 9.672 8.049 15.000
20 7.026 1 I 9.262 20.000
25 7.636 13.817 10.140 .". 111111
30 8.129 15.616 10.830 30.000
Table 4: Comparison of OCC performance, exponential distribution. Throughput is reported
process slowdowns and failures, and can also provide better performance than blocking data structures
by permitting fast operations to occur at the expense of slow operations.
A nonblocking data structure avoids the use of locks by using optimistic concurrency control instead
(relying on the use of the compareandswap instruction). As a result, the performance of nonblocking
data structures can't be analyzed by using the analytical tools developed for locking data structures
[10, 11, 12]. This work was motivated by the desire to develop tools for analyzing nonblocking data
structures.
We developed a simple nonblocking queue that permits an enqueue to occur in parallel with a dequeue
operation [20]. We wrote a detailed simulation to compare the performance of the nonblocking queue
to a locking queue. We modeled the processors in the parallel computer as being either constant speed
or varying speed. In the constant speed model, the processors are divided into fast and slow processors.
When an operation enters to compete for the queue, it is assigned a fast or a slow processor with a fixed
probability. In the varying speed model, all processors are identical, but the processors cycle between
being slow or fast. When an operation enters the system, it is assigned a processor, which can be in
either the fast or in the slow state.
Our simulation results showed the surprising result that nonblocking queue has worse performance
than the blocking queue in the constant speed model, but better performance in the varying speed model
[21]. In order to examine this phenomenon more closely, we analyze the queue using the V/F and the
V/V models.
In the nonblocking queue, the enqueue operations are serialized with respect to each other, and so
are the dequeue operations, but an enqueue operation conflicts with a dequeue operation only when the
queue is empty. We model the enqueue stream only and assume that the queue never becomes empty.
Therefore, every operation conflicts with every other, so 4 = 1. We use two transaction classes to model
the fast and slow processors. The first transaction class models the fast processors. Its execution time
is chosen uniformly randomly in [.8, 1.2], and fi = .9. The execution time of the second transaction
class, which represents the slow processors, is chosen uniformly randomly in [8, 12], and f2 = .1. The
VF transaction model represents the case in which the operation chooses a fast or a slow processor when
it begins execution, and the VV model represents the case in which the processor that is executing the
operation is usually fast but occasionally becomes slow.
We plot the throughput of the nonblocking queue for the constant speed and the varying speed models
against increasing V in figure 2. For comparison, we also plot the throughput of the locking algorithm
algorithm, which is a constant 1/b = 1/1.9. The nonblocking queue in the constant speed model has
a lower throughput than the locking queue, in spite of the preference shown towards fast executions in
the VF model. The nonblocking queue has a poor throughput in the constant speed model because of
the extremely long times required for the completion of the operations executed on the slow processors.
These running times are shown in figure 3. The throughput of the variable speed model increases with
increasing V, and is considerably greater than that of the locking queue. These model predictions are in
agreement with our simulation results [21].
6 Conclusion
In this paper, we have extended the OCC performance model due to Ryu and Thomasian (which we call
the FF model) to handle transactions that resample their execution time if they abort (VF transaction
model), and also to handle transactions that change their transaction class (VV transaction model). We
present performance models for static/silent, static/broadcast, dynamic/silent, and dynamic/broadcast
optimistic concurrency control. We validate each of the models by comparison to simulation results.
We investigate the performance of OCC under the VF and VV models and find that the throughput
of the transaction processing system increases as the variance in the execution times increase In contrast,
the throughput of a transaction processing system running FF transactions decreases with increasing
variance in execution times. We compare the performance of the different OCC schemes for the VF
model, and find that SS < DS < SB < DB in terms of throughput. The FF model orders the OCC
schemes differently, giving SS < SB < DS < DB in terms of throughput. Therefore, if the VF model
applies to he transactions, it is better to implement broadcast optimistic concurrency control than it is
to implement dynamic concurrency control.
We apply the new OCC performance models to the analysis of nonblocking data structures. We find
that nonblocking data structures perform worse than locking data structures in a NonUniform Mem
ory Architecture (NUMA) architecture, but better than locking data structures in a Uniform Memory
Architecture (UMA) architecture.
References
[1] K.E. Atkinson. An Introduction to Numerical Analysis. John Wiley and Sons, 1978.
[2] P.A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database
Systems. AddisonWesley, 1 1 .
[3] H.A. David. Order Statistics. John Wiley, 1981.
[4] A. Gottlieb, B. D. Lubachevsky, and L. Rudolph. Coordinating large numbers of processors. In
Proceedings of the International Conference on Parallel Processing. IEEE, 1981.
[5] T. Harder. Observations on optimistic concurrency control schemes. Inform. Systems, 9(2):111120,
1984.
[6] J. Haritsa. Transaction scheduling in firm realtime database systems. Technical Report TR1036,
University of WisconsonMadison, Dept. of CS, 1991.
[7] M. Herlihy. A methodology for implementing highly concurrent data structures. In Proceeding of
the Second AC if SIGPLAN Symposium on Principles and Practice of Parallel Programming, pages
197206. AC,\I 1989.
[8] M. Herlihy and J. Wing. Axioms for concurrent objects. In Fourteenth AC if Symposium on Prin
ciples of Programming Languages, pages 1326, 1 I7.
[9] J. Huang, J. Stankovic, K. Ramamritham, and D. Towsley. Experimental evaluation of realtime
optimistic concurrency control schemes. In Proc. 17th VLDB, 1991.
[10] T. Johnson. The Performance of Concurrent Data Structure Algorithms. PhD thesis, NYU Dept.
of Computer Science, 1990.
[11] T. Johnson and D. Shasha. A framework for the performance analysis of concurrent Btree algo
rithms. In AC if SIGACT/SIC i[OD/SIGART Symposium on Principles of Database Systems, pages
273287, 1990.
[12] T. Johnson and D. Shasha. The performance of concurrent data structure algorithms. Transactions
on Database Systems, 1992. to appear.
[13] L. Kleinrock. Queueing Systems, volume 1. John Wiley, New York, 1 Ii
[14] H.T. Kung and J.T. Robinson. On optimistic methods for concurrency control. AC if Transactions
on Database Systems, 6(2):213226, 1981.
[15] L. Lamport. Specifying concurrent program modules. AC if Trans. on Programming Languages and
Systems, 5(2):190222, 1983.
[16] V. Lanin and D. Shasha. Concurrent set manipulation without locking. In Proceedings of the Seventh
AC if Symposium on Principles of Database Systems, pages 211220, 1988.
[17] D. Menasce and T. Nakanishi. Optimistic vs. pessimistic concurrency control mechanisms in
database management systems. Information Systems, 7(1):1327, 1982.
[18] R. Morris and W. Wong. Performance of concurrency control algorithms with nonexclusive access.
In Performance '84, pages 87101, 1984.
[19] R. Morris and W. Wong. Performance analysis of locking and optimistic concurrency control algo
rithms. Performance Evaluation, 5:105118, 1 I
[20] S. Prakash, Y.H. Lee, and T. Johnson. A nonblocking algorithm for shared queues using compare
andswap. In Proc. I,, / Conf. on Parallel Processing, pages II68II75, 1991.
[21] S. Prakash, Y.H. Lee, and T. Johnson. Nonblocking algorithms for concurrent data structures.
Technical report, University of Florida Dept. of CIS, 1991. Available at cis.ufl.edu:cis/tech
reports/tr91/tr91.002.ps.Z.
[22] J.T. Robinson. Experiments with transaction processing on a multiprocessor. Technical Report
RC' i;, IBM, Yorktown Heights, 1982.
[23] S.M. Ross. Stochastic Processes. John Wiley, 1983.
[24] I.K. Ryu and A. Thomasian. Performance analysis of centralized database with optimistic concur
rency control. Performance Evaluation, 7:195211, 1 I7.
[25] J. Stone. A simple and correct sharedqueue algorithm using compareandswap. Technical Report
RC 1'l"., IBM TJ Watson Research Center, 1990.
[26] Y.C. Tay, R. Suri, and N. Goodman. Locking performance in centralized databases. AC if Trans
actions on Database Systems, 10(4):415462, 1 1".
[27] R. Treiber. Systems programming: Coping with parallelism. Technical Report RJ 5118, IBM
Almaden Research Center, 1986.
[28] J. Turek. Resilient Computation in the Presence of Slowdowns. PhD thesis, NYU Dept. of Computer
Science, 1991.
[29] J.D. Valois. Analysis of a lockfree queue. Submitted for publication, 1992.
[30] J.D. Valois. Concurrent dictionaries without locks. Submitted for publication, 1992.
[31] P.S. Yu, D.M. Dias, and S.S. Lavenberg. On modeling database concurrency control. Technical
Report RC 15368, IBM Research Division, 1990.
[32] P.S. Yu, H.U Heiss, and D.M Dias. Modeling and analysis of a timestamp history based certification
protocol for concurrency control. IEEE Transactions on Knowledge and Data Engineering, 3(4):525
537, 1991.
Throughput
1.4 r
V
constant speed model varying speed model locking queue
Figure 2: Throughput of the locking queue and the nonblocking queue in the constant speed and the
varying speed model
Residence time
V
VF slow operation
Figure 3: Response time of the slow operations in the constant speed model
