Computer Architecture Data Representation Mark S. Staveley [email protected].
Sathya Peri, IIT Patna, India, [email protected]@mun.ca K.Vidyasankar, Memorial University, St...
-
Upload
ronald-hill -
Category
Documents
-
view
231 -
download
6
Transcript of Sathya Peri, IIT Patna, India, [email protected]@mun.ca K.Vidyasankar, Memorial University, St...
Sathya Peri, IIT Patna, India, [email protected], Memorial University, St John’s, Canada, [email protected]
1
Efficient Non-Blocking Conflict Notion for Nested Transactions
Overview
2
Introduction to Closed Nested TransactionsWrite and Read operations in closed nested
transactionslastWrite definition
Specification of lastWrite operations for read:
Blocking specifiction, lwSpecNon-blocking specification, nblwSpec
Non-blocking Conflict notion
Nesting of Transactions
3
A transaction is nested: if it invokes another transaction
Composing of transaction can be achieved through nestingComposition: basis of modular programming
Different types of nesting: Closed, Open and Flat
Our Focus: Closed Nesting
4
We focus only on nested transactions with read and write operations
Let P be a parent transaction which invokes a sub-transaction S
In closed nesting, when the sub-transaction S commits its effects are not visible to other 'external'
transactions immediately, i.e., it is localthey become visible when its parent
transaction P commitsAbort of the sub-transaction S has no affect
on P
Illustration: Closed Nesting
5
Memory
x=5
P
S
Q
Closed Nesting
x=10
write(x,10)
read(x) = 5read(x) = 10
committed
committed
Background Information: Schedule Representation
Schedule: r11(x) r211(y) w212(y) c21 w12(y) c1 r221(y) w222(z) c22 a2 r31(z) w32(b) c1
6
tR
t1
t2 t3
t21 t22
r211(y)
w212(y)
r221(y)
w222(z)
w32(b)
r31(z)
r11(x)
w12(y)
tinittfin
Write Operation – Lazy Write approachA transaction maintains a local buffer for
every data-item it writes to.All the writes of a transaction are onto the
local buffers.When the transaction commits, the
contents of the buffers are merged with its parent’s buffers.
On abort the buffers are discarded
7
Schedule Augmentation: Commit WritesWe augment a schedule with extra write
operations: Commit Write operationsIn a schedule,
There is a commit-write operation for every data-item, a committed (sub)transaction writes to
Aborted (sub) transactions do not have commit-write operations
A commit-write represents the merging of a write of a transaction on a data-item with its parent’s write
Simple memory write operation’s commit write is itself
8
Background Information: Schedule Representation
Augmented Schedule: r11(x) r211(y) w212(y) w21
212(y) c21 w12(y) w112(y) c1 r221(y) w222(z)
w22222(z) c22 a2 r31(z) w32(b) w3
32(b) c3
9
tR
t1
t2 t3
t21 t22
r211(y)
w212(y)
r221(y)
w222(z)
w32(b)
r31(z)
r11(x)
w12(y)
tinittfin
Observation on Write and Commit OperationsThe write operation of a nested transaction
ts involves only its local buffers
The commit of a sub-transaction ts with parent tp only involves the buffers of tp
Observation: Write and Commit operations be implemented atomically, possibly using locks
10
Read Operation – Closest AncestorA transaction performing a read operation
on data-item d starts with its local write buffers.
If the data item is not present, then it accesses the buffers of its ancestors in
increasing order of heightreads from the buffers of an ancestor closest
to itA write operation read by a given read
operation is denoted as the read’s lastWrite.
11
lastWrite Specification: Non-nested transactionsIn single version database schedules, the
lastWrite for a read operation ri(x) belonging to transaction ti is:
The previous closest write on the data-item x by a transaction ti, wj(x)
For instance consider the following schedule of non-nested transactions: r1(x) r2(x) w1(z) r2(y) w2(y) r1(z) w3(z)
lastWrite of r1(z) is w1(z)
12
lastWrite Specification: Nested transactionsIn nested transactions, by reading from the
closest ancestor the notion of lastWrite can be defined
The lastWrite of a read operation ri(x) in a nested transaction is either a simple write or committed write wj(x) which:Occurs before the readIs a peer of the read or the peer of an
ancestor of the readIs closest in terms of tree heightIs closest in terms of schedule distance We denote this specification of lastWrite as
lwSpec13
Examples of LastWrite using lwSpec
r11(x) : init(x), r211(y):init(y), r221(y): w21212(y)
r31(z):init(z)
14
tR
t1
t2 t3
t21 t22
r211(y)
w212(y)
r221(y)
w222(z)
w32(b)
r31(z)
r11(x)
w12(y)
tinittfin
Limitations of lwSpeclwSpec implicitly assumes that the read
operations are atomicSpecifically, it assumes that no other
operation is being executed when a read is in progress
A read operation that follows closest ancestor option, involves buffers of multiple transactionsHence can not be implemented atomicallyEach read operation is represented as a
leaf node in the treeTo correctly capture the read, we
assume that the node implies the instant the read completes
15
Limitations of lwSpec: illustrationConsider a nested transaction ti at level 10
(in the tree) wishing to read x, ri(x). Consider this sequence
When the control (of the read) reaches a transaction tj at level 9, it does not find any buffer for x
The control goes to transaction tk at level 8 and still does not find x. At that point suppose transaction tj writes to x
The control finally reaches a transaction tj
at level 7 and reads x This implies that the last two conditions of the
lwSpec are not true. 16
Non-blocking lastWrite Specification: nblwSpecThe lastWrite of a read operation ri(x) in a
nested transaction is either a simple write or committed write wj(x) which:Occurs before the readIs a peer of the read or the peer of an
ancestor of the readWe denote this specification of lastWrite as
nblwSpecIt must be noted that given a schedule,
for a given read ri(x), there could be multiple writes in the
schedule that satisfy the nblwSpec (unlike lwSpec, where there is only one write)
thus, in this case an external entity should specify the lastWrite for each read operation
17
lastWrite Specification and Conflict notionBased on the specification of the lastWrite,
the correctness for the correctness criteria can be defined
Two data operations on the same data-item are conflicting:
if one of them is a write operationThen, based on the correctness criteria,
accurate conflict notions can be defined• Using accurate conflict notion, efficient
algorithms can be devised• Similar to Conflict Serializability in
databases18
External ReadsFor a transaction, we define
External-read: A read operation belonging to a descendant, whose lastWrite is external to the transaction
A simple-memory read is an external read of itself
19
Non-blocking Conflict NotionFor any two nodes (transactions/simple
memory operations) in the tree na and nb, which contain two operations oa and ob are in conflict if:
w-w conflict: oa and ob are commit-writes respectively wa and wb
w-r conflict: oa is a commit-write of na, wa and ob is an external read of nb, rb .
r-w conflict: oa is an external-read of na, ra and ob is a commit-write of nb,wb.Let the lastWrite of ra be wl . This conflict is true if S.ord(wl) < S.ord(wb) and S.level(wl) < S.level(wb)
20
ConclusionCharacterized the non-blocking
specification of lastWrites, nblwSpecDeveloped conflict notions based on these
non-blocking specification
21
Questions?
22