Transcript Principles of Computer System Design  Saltzer & Kaashoek procedure TRANSFER (debit_ac count , c redit _acc ount , amount.

Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure TRANSFER (debit_ac count , c redit _acc ount , amount )
GET dbdat a, debi t_ac count 
dbdat a  dbdat a - amount
PUT ( dbdat a, debit_ac count )
GET c rdata, credit_ac count 
c rdata c rdata + amount
PUT ( c rdata, credit_ac count )
Principles of Computer System Design  Saltzer & Kaashoek
2009
Human user
g ener ati ng
req uests
Interface
Cal endar manag er
layer i nterface
Typical i nstruction
across this interface
Add new event on
Februar y 27
Cal endar
Progr am
Java l anguag e
layer i nterface
nextch = instring[j];
Java
Interpreter
Machine lang uag e
layer i nterface
add
R1,R2
hardwar e
Principles of Computer System Design  Saltzer & Kaashoek
2009
All-or-nothing atomicity
A sequence of steps is anall-or-nothing action
if, f rom the point of view of its
invoker, the sequence always either
completes
,
or
aborts in such a way that it appears that the sequence had never been
undertaken in the first place. Thatbacks
is, it out.
Principles of Computer System Design  Saltzer & Kaashoek
2009
Bef ore-or-af ter atomicity
Concurrent actions hav
e thebefore-or-after pro perty if their ef f ectom
f r the point of
view of their inv
okers is the same as if the actions occurr
ed eithercompletely befor
e
or completely afterone another
.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure TRANSFER (reference debit_account , reference credit_account, amount )
debit_account  debit_account - amount
credit_account  credit_account + amount
TRANSFER
(A, B, $10)
TRANSFER
(B, C, $25)
Principles of Computer System Design  Saltzer & Kaashoek
2009
Thr ead #2 ( debit_ac count i s B)
2–1
R EAD B
.
.
.
2–2
WR ITE B
Thr ead #1 ( c redit _acc ount i s B)
1–1
R EAD B
.
.
.
1–2
WR ITE B
corr ect r esul t:
case 1: Thr ead #1: R EAD B
Thr ead #2:
Value of B: 100
case 2: Thr ead #1:
Thr ead #2: R EAD B
Value of B: 100
wrong results:
case 3: Thr ead #1: READ B
Thr ead #2:
Value of B: 100
case 4: Thr ead #1: READ B
Thr ead #2:
Value of B: 100
ti me
WRITE
B
READ
B
WR ITE
B
110
85
READ
WRITE
B
WR ITE
B
B
75
85
WRITE
REA D
B
B
WR ITE
B
110
R EAD
B
W RITE
75
WR ITE
B
B
75
case 5: Thr ead #1:
Thr ead #2: REA D B
Value of B: 100
REA D
case 6: Thr ead #1:
Thr ead #2: REA D B
Value of B: 100
R EAD
B
WR ITE
110
B
WR ITE
B
110
B
75
W RITE
W RITE
B
B
75
110
Principles of Computer System Design  Saltzer & Kaashoek
2009
old system
state
action
new system
state
acti on #1
old system
state
acti on #2
new system
state
acti on #3
Principles of Computer System Design  Saltzer & Kaashoek
2009
AA#3
AA #2
AA
#1
fi nal
state
A
AA#3
AA
#2
old system
state
AA #2
AA#3
AA#1
fi nal
state
B
fi nal
state
C
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure AU DIT ()
s um  0
for each W  in bank. ac counts
s um  s um + W.bal ance
if ( s um ° 0) c al l for inves ti gation
//
TRANSFER
, in thread 1
// in thread 2
debit_account  debit_account - amount
…
…
AU DIT
credit _account  credit _account + amount
…
()
Principles of Computer System Design  Saltzer & Kaashoek
2009
Atomicity
An action is
atomic if there is no way for a higher layer to discover the inter
structure of its implementation
.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure AL MOST _AL L _OR_NOTHING _PUT (data , all_or_not hing_s ec tor )
CAREFUL _PUT ( data , all_or_not hing_s ec tor .S1)
CAREFUL _PUT ( data , all_or_not hing_s ec tor .S2)
// Commit point.
CAREFUL _PUT ( data , all_or_not hing_s ec tor .S3)
procedure AL L _OR _NOTHING _GET (reference data , all_or_not hing_s ec tor )
CAREFUL _GET (data1 , all_or_not hing_s ec tor .S1)
CAREFUL _GET (data2 , all_or_not hing_s ec tor .S2)
CAREFUL _GET (data3 , all_or_not hing_s ec tor .S3)
if data1 = data2 then data  data1
// Ret urn new value.
else data  data3
// Ret urn old value.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure AL L _OR _NOTHING _PUT ( data, all_or_not hing_sector )
CHECK _AND _REPAIR (all_or_not hing_sector )
AL MOST _AL L _OR_NOTHING _ PUT (data , all_or_not hing_sector )
procedure CHECK _AND _REPAIR (all_or_not hing_sector )// Ensure copies mat ch.
CAREFUL _GET (data1 , all_or_not hing_sector .S1)
CAREFUL _GET (data2 , all_or_not hing_sector .S2)
CAREFUL _GET (data3 , all_or_not hing_sector .S3)
if (data1 = data2 ) and (data2 = data3 ) return // State 1 or 7, no repair
if (data1 = data2 )
CAREFUL _PUT (data1 , all_or_not hing_sector .S3) return // State 5 or 6.
if (data2 = data3 )
CAREFUL _PUT (data2 , all_or_not hing_sector .S1) return // State 2 or 3.
CAREFUL _PUT ( data1 , all_or_not hing_sector .S2)
// State 4, go t o st at e 5
CAREFUL _PUT ( data1 , all_or_not hing_sector .S3)
// State 5, go t o st at e 7
data state:
1
2
3
4
5
6
7
sector S1
sector S2
sector S3
old
old
old
bad
old
old
new
old
old
new
bad
old
new
new
old
new
new
bad
new
new
new
Principles of Computer System Design  Saltzer & Kaashoek
2009
___
___
___
begin all-or-nothing action
___
___
___
arbitrary s equence of
___
lower-layer ac tions
___
end all-or-nothing action
___
___
___
}
Principles of Computer System Design  Saltzer & Kaashoek
2009
___
___
___
___
___
___
___
___
___
___
___
___
___
first step of all-or-not hing action
}
Pre-commit discipline : can back out,
leaving no trace
Commit point
}
Post-commit discipline : completion is inevit able
last step of all-or-not hing action
Principles of Computer System Design  Saltzer & Kaashoek
2009
The golden rule of atomicity
Never modify the only copy!
Principles of Computer System Design  Saltzer & Kaashoek
2009
Var iable A:
7
20
5
29
112
14
Histor y of earli er versions
16
Tentative
next version
Cur rent version
Principles of Computer System Design  Saltzer & Kaashoek
2009
All- or -nothing Journal Stor ag e System
NEW_A CTION
REA D
Cel l Storag e
System
R EAD _C UR RENT _VA LU E
W RITE
WR ITE _NEW _VA LUE
Journal
Stor ag e
Manager
– catalog s
AL LOC ATE
COM MIT
DEAL L OCATE
– versions
– outcome
records
AB ORT
Principles of Computer System Design  Saltzer & Kaashoek
2009
all-or- nothing
acti on
commits
non-existent
committed
pending
new all- or- nothing
acti on is
created
all-or- nothing
acti on
aborts
discar ded
aborted
outcome recor d
state no long er
of any inter est
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure NEW _ACTION ()
id  NEW _OUTCOME _RECORD ()
id.out come_record.st at e  PENDING
return i d
procedure COMMIT (reference id)
id.out come_record.st at e  COMMITTED
procedure ABORT (reference id)
id.out come_record.st at e  ABORTED
Principles of Computer System Design  Saltzer & Kaashoek
2009
Obj ect A
value:
7
all-or- nothing 03
acti on id:
1101:
committed
24
15
1101
1423
1423:
aborted
75
1794
1794:
pending
outcome
records
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure READ _CURRENT _VALUE (data_id, caller_id )
starting at end of data_id repeat until beginning
v  previous version of dat a_id
// Get next older version
a v.action_id // Identify the action a t hat creat ed it
s  a.outcome_record. st at e
// Check act ion a’s out come record
if s = COMMITTED then
return v.value
else skip v
// Continue backward search
signal (“Tried to read an uninitialized variable!”)
procedure WRITE _NEW _VALUE (reference data_id , new_value, caller_id )
if caller_id .outcome_record .stat e = PENDING
append new version v to data_id
v.value  new_value
v.action_id  caller_id
else signal (“Tried to writ e outside of an all-or-not hing act ion!”)
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure TRANSFER (reference debit_account , reference credit_account , amount )
my_id  NEW _ ACTION ()
xvalue  READ _CURRENT _VALUE (debit_account, my_id )
xvalue  xvalue - amount
WRITE _ NEW _VALUE (debit_account , xvalue, my_id )
yvalue  READ _CURRENT _VALUE (credit_account, my_id )
yvalue  yvalue + amount
WRITE _ NEW _VALUE (credit_account , yvalue, my_id )
if xvalue > 0 then
COMMIT (my_id )
else
ABORT (my_id )
signal(“Negative transfers are not allowed.”)
Principles of Computer System Design  Saltzer & Kaashoek
2009
Journal Storag e
Log
log
WRITE _NEW_V AL UE
install
curr ent
end of log
Cel l
Stor ag e
R EAD _CU R RENT _VA LU E
Principles of Computer System Design  Saltzer & Kaashoek
2009
Volati le storag e
In-memory database:
Ordinar y database:
Hig h- performance
database:
Application
prog r am
Non-vol ati le storag e
log
cell
stor ag e
Application
prog r am
log
cell
stor ag e
Application
prog r am
log
cell
stor ag e
cache
Principles of Computer System Design  Saltzer & Kaashoek
2009
Write-ahead-log protocol
Log the update before installing it.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure TRANSFER (debit_ac count , c redit _acc ount , amount )
my_id  LOG ( BEGIN _TRANSACTION )
dbvalue. old  GET (debit_ac count )
dbvalue .new  dbvalue. old - amount
c rvalue. old  GET (c redit _acc ount , my_id )
c rvalue. new  c rvalue. old + amount
LOG ( CHANGE , my_id,
“ PUT (debit_ac count , dbvalue. new )”,
//redo act ion
“ PUT (debit_ac count , dbvalue. old )” )
//undo act ion
LOG ( CHANGE , my_id ,
“ PUT (c redit _acc ount , c rvalue. new )”
//redo act ion
“ PUT (c redit _acc ount , c rvalue. old)”)
//undo act ion
PUT (debit_ac count , dbvalue. new )
// inst all
PUT (c redit _acc ount , c rvalue. new )
// inst all
if dbvalue. new > 0 then
LOG ( OUTCOME , COMMIT , my_id )
else
LOG ( OUTCOME , ABORT , my_id )
signal(“Ac tion not allowed. Would make debit acc ount negat ive. ”)
LOG ( END _TRANSACTION , my_id )
Principles of Computer System Design  Saltzer & Kaashoek
2009
type: C HANGE
type: OUTCOME
action_id: 9974
status: COMM ITTED
action_id : 9979
… redo_action :
PUT (debit_account,
$90)
undo_action :
PUT (debit_account, $120)
older log r ecor ds
type :
CHANGE
action_id: 9979
redo_action :
PUT (credit_account , $40)
undo_action :
PUT (credit_account , $10)
newer log records
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure ABORT (action_id )
starting at end of log repeat until beginning
log_record  previous record of log
if log_record.id = action_id then
if (log_record.t ype = OUTCOME )
then signal (“Can’t abort an already c ompleted ac tion. ”)
if (log_record.t ype = CHANGE )
then perform undo_ac tion of log_record
if (log_record.t ype = BEGIN )
then break repeat
LOG (action_id , OUTCOME , ABORTED )
// Block future undos .
LOG (action_id , END )
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure RECOVER ()// Recovery procedure for a volatile, in-memory dat abase.
winners  NULL
starting at end of log repeat until beginning
log_record  previous record of log
if ( log_record.t ype = OUTCOME )
then winners  winners + log_record
// Set addition.
starting at beginning of log repeat until end
log_record  next record of log
if ( log_record.t ype = CHANGE )
and ( outcome_record  find (log_record.act ion_id) in winners )
and (outcome_record.st at us = COMMITTED ) then
perform log_record .redo_action
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure RECOVER ()// Rec overy proc edure for non-volatile cell memory
c omplet eds  NULL
losers  NULL
starting at end of log repeat until beginning
log_record  previous record of log
if ( log_record.t ype = END )
then c omplet eds  c omplet eds + log_record
// Set addition.
if ( log_record.act ion_id is not in c omplet eds ) then
losers  losers + log_record
// Add if not already in s et.
if (log_record.t ype = CHANGE ) then
perform log_record.undo_action
starting at beginning of log repeat until end
log_record  next record of log
if ( log_record.t ype = CHANGE )
and (log_record.act ion_id. s tat us = COMMITTED ) then
perform log_record.redo_ac tion
for each log_record in losers do
log (log_record.act ion_id , END )
// Show ac tion c omplet ed.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure RECOVER ()
// Rec overy proc edure for rollback recovery.
c omplet eds  NULL
losers  NULL
starting at end of log repeat until beginning
// Perform undo s can.
log_record  previous record of log
if ( log_record.t ype = OUTCOME )
then c omplet eds  c omplet eds + log_record
// Set additi on.
if ( log_record.act ion_id is not in c omplet eds ) then
losers  losers + log_record
// New l os er.
if (log_record.t ype = CHANGE ) then
perform log_record.undo_ac ti on
for each log_record in losers do
log (log_record.act ion_id , OUTCOME , ABORT )
// Block future undos .
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure BEGIN _TRANSACTION ()
id  NEW _OUTCOME _RECORD ( PENDING )
// Create, initialize, assign id.
previous_id  id – 1
wait until previous_id. outcome_record. state ° PENDING
return id
Principles of Computer System Design  Saltzer & Kaashoek
2009
value of object at end of transaction
Obj ect
1
2
3
A
0
+10
B
0
-10
C
0
D
0
outcome
record
state
Committed
4
5
+12
6
0
-6
-12
-4
+2
-2
-2
Committed Committed
transact ion
Aborted
Committed Pendi ng
1: init ial ize all ac counts to 0
2: t rans fer 10 from B t o A
3: t rans fer 4 from C t o B
4: t rans fer 2 from D t o A (aborts )
5: t rans fer 6 from B t o C
6: t rans fer 10 from A t o B
Principles of Computer System Design  Saltzer & Kaashoek
2009
Obj ect
1
OUTC OME
record
state
2
Value of object at end of tr ansaction
3
4
5
6
7
A
0
+10
+10
+12
+12
0
0
B
0
-10
-6
-6
-12
-2
-2
C
0
0
-4
-4
+2
+2
+2
D
0
0
0
-2
-2
-2
-2
Committed
Committed Committed
Aborted Committed
Pendi ng
Pendi ng
Unchanged val ue
Chang ed val ue
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure READ _CURRENT _VALUE (data_id , this_transaction_id )
starting at end of data_id repeat until beginning
v  previous version of data_id
last_modifier  v.action_id
if last_modifier • this_transaction_id then skip v
// Keep searching
wait until (last_modifier.outcome_record.state ° PENDING )
if (last_modifier.outcome_record.state = COMMITTED )
then return v.state
else skip v
// Resume search
signal (“Tried to read an uninitialized variable”)
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure NEW _VERSION (reference data_id , this_t ransaction_id )
if this_t ransaction_id.out come_record.mark_state = MARKED then
signal (“Tried to create new version after announcing mark point !”)
append new version v to data_id
v.value  NULL
v.action_id  transact ion_id
procedure WRITE _VALUE (reference data_id , new_value , this_t ransaction_id )
starting at end of data_id repeat until beginning
v  previous version of data_id
if v.action_id = this_t ransaction_id
v.value  new_value
return
signal (“Tried to writ e without creat ing new version!”))
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure BEGIN _TRANSACTION ()
id  NEW _OUTCOME _RECORD (PENDING )
previous_id  id - 1
wait until (previous_id. outcome_record. mark_state =
or (previous_id. outcome_record. st ate ° PENDING )
return id
MARKED
)
procedure NEW _OUTCOME _RECORD ( starting_state)
ACQUIRE (outcome_record_lock )
// Make this a before-or-after action.
id  TICKET ( outcome_record_sequencer )
allocate id.out come_record
id.out come_record.state  starting_state
id.out come_record.mark_state  NULL
RELEASE (outcome_record_lock )
return id
procedure MARK _POINT _ANNOUNCE (reference this_t ransaction_id )
this_t ransaction_id.out come_record.mark_state  MARKED
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure
(reference debit_account , reference credit _account ,
amount )
my_id  BEGIN _TRANSACTION ()
NEW _VERSION (debit_account , my_id )
NEW _VERSION (credit _account , my_id)
MARK _POINT _ANNOUNCE (my_id );
xvalue  READ _CURRENT _VALUE (debit_account , my_id )
xvalue  xvalue - amount
WRITE _VALUE (debit_account , xvalue , my_id)
yvalue  READ _CURRENT _VALUE (credit _account , my_id )
yvalue  yvalue + amount
WRITE _VALUE (credit _account , yvalue , my_id )
if xvalue > 0 then
COMMIT (my_id )
else
ABORT (my_id)
signal(“Negative t ransfers are not allowed.”)
TRANSFER
Principles of Computer System Design  Saltzer & Kaashoek
2009
Value of object at end of transacti on
A
1
2
0
+10
3
4
5
+12
HWM=2
B
C
0
HWM=2
HWM=6
-10
H WM=3
0
-6
-4
HWM=3
D
0
H WM=5
H WM=5
-12
H WM=6
6
7
0
+2
HWM=7
-2
+2
-2
H WM=7
HWM=4
Committed
Committed
Committed
Aborted Committed
Pendi ng
-4
Pendi ng
Outcome state record
HWM=
Confli ct: Must abort!
Hig h- water mark
Confli ct
Chang ed val ue
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure READ _CURRENT _VALUE (reference data_id , value , caller_id )
starting at end of data_id repeat until beginning
v  previous version of data_id
if v.action_id • caller_id then skip v
examine v.action_id. outcome_record
if PENDING then
WAIT for v.action_id t o COMMIT or ABORT
if COMMITTED then
v.high_water_mark  max(v.high_water_mark , caller_id )
return v.value
else skip v
// Continue backward search
signal (“Tried to read an uninitialized variable!”)
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure NEW _VERSION (reference data_id , c aller_id )
if ( c aller_id < data_id. high_wat er_mark )
// Conflict with later reader.
or (c aller_id < ( LATEST _VERSION [data_id ].action_id ))
// Blind write c onflict .
then ABORT t his t rans ac tion and terminate this thread
add new vers ion v at end of data_id
v.value  0
v.ac tion_id  c aller_id
procedure WRITE _VALU E (reference data_id , new_value , c aller_id)
locate version v of data_id. his tory such that v.ac tion_id = c aller_id
(if not found, signal (“Tried to writ e wit hout c reating new version! ”))
v.value  new_value
Principles of Computer System Design  Saltzer & Kaashoek
2009
architectur al
instructi on
reg ister
physical
reg ister
n
R5
42
n+ 1
R4
61
n+ 2
R5
29
0
three entri es in the reor der buffer
127
physical reg ister fil e
with 128 reg ister s
n
R5  R4  R2
n + 1 R4  R5 + R1
n + 2 R5  READ (117492)
// Write a result in register five.
// Use result in register five.
// Write content of a memory cell in register five.
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure PAY _INTEREST (reference account )
if account.balance > 0 then
interest = account.balance * 0. 05
TRANSFER (bank, account , interest )
else
interest = account.balance * 0.15
TRANSFER (account , bank, interest )
procedure MONTH _END _INTEREST :()
for A  each customer_account do
PAY _INTEREST (A)
Principles of Computer System Design  Saltzer & Kaashoek
2009
MONTH _END _INTERES T
outcome:
super ior :
PAY _INTERES T1
outcome:
super ior :
super ior :
none
PAY _INTERES T 2
(1st invocation )
outcome:
COM MITTED
MO NTH _END _INTER EST
super ior :
(2nd invocation )
PENDING
M ONTH_END _INTERES T
TR ANSFER2
TR ANSFER1
outcome:
PENDING
outcome:
COM MITTED
super ior :
PA Y _INTER EST
PENDING
PA Y _INTER EST
2
1
OK for TR ANSFER 2
to r ead?
creator:
TRA NS FE R1
newest ver sion of
account bank
Principles of Computer System Design  Saltzer & Kaashoek
2009
From: Alice
To: Bob
Re: my transaction 91
if (Charles does Y and Dawn does Z) then do X, please.
Principles of Computer System Design  Saltzer & Kaashoek
2009
From:Alic e
To: Bob
Re: my transact ion 271
Please do X as part of my transact ion.
From:Bob
To: Alic e
Re: your t rans ac tion 271
My part X is ready to commit.
Two-phase-c ommit mess age #1:
From:Alic e
To: Bob
Re: my transact ion 271
PREPARE
t o c ommit X.
Two-phase-c ommit mess age #2:
From:Bob
To:Alic e
Re: your t rans ac tion 271
I am
PREPARED
t o c ommit my part. Have you dec ided to c ommit yet?
Two-phase-c ommit mess age #3
From:Alic e
To:Bob
Re: my transact ion 271
My trans act ion c ommit ted. Thanks for your help.
Principles of Computer System Design  Saltzer & Kaashoek
2009
Coordinator
Alice
Wor ker
Bob
Wor ker
Charl es
Wor ker
Dawn
log B EGIN
PREPA RE
X
PREPA RE
Y
PR EPARE
Bob is
Z
log B EGIN
PR EPARE D
log PREPA RED
Charl es is
PR EPAR ED
Dawn is
PR EPAR ED
Time
log
C OMMITTED
C OMM IT
COM MIT
COMM IT
log C OMMITTED
Principles of Computer System Design  Saltzer & Kaashoek
2009
From:Julius Caesar
To:Titus Labienus
Dat e:11 January
I propos e to cros s the Rubic on and attac k at dawn t omorrow. OK?
From:Titus Labienus
To:Julius Caesar;
Dat e:11 January
Agreed, dawn on the 12th.
or
From:Titus Labienus
To: Julius Caesar
Dat e: 11 January
No. I am await ing
reinforcements from Gaul .
From:Julius Caesar
To:Titus Labienus
Dat e:11 January
The di e i s cast .
Principles of Computer System Design  Saltzer & Kaashoek
2009
procedure AL L _OR _NOTHING _DURABL E _GET (reference data , atomic_sect or)
ds  CAREFUL _ GET (data , atomic_sect or.D0)
if ds = BAD then
ds  CAREFUL _GET (data , atomic_sect or.D1)
return ds
procedure AL L _OR _NOTHING _DURABL E _PUT (new_dat a , atomic_sect or)
SALVAGE (atomic_sect or)
ds  CAREFUL _ PUT (new_dat a , atomic_sect or.D0)
ds  CAREFUL _ PUT (new_dat a , atomic_sect or.D1)
return ds
procedure SALVAGE (atomic_sect or)
//Run this program every Td seconds.
ds0  CAREFUL _GET (data0 , atomic_sect or.D0)
ds1  CAREFUL _GET (data1 , atomic_sect or.D1)
if ds 0 = BAD then
CAREFUL _PUT (data1 , atomic_sect or.D0)
else if ds1 = BAD then
CAREFUL _PUT (data0 , atomic_sect or.D1)
if data0 ° data1 then
CAREFUL _PUT (data0 , atomic_sect or.D1)
D0:
data 0
D1 :
data 1
Principles of Computer System Design  Saltzer & Kaashoek
2009