roberto palmieri – workshop on distributed transactional memory (wdtm 2012) - 22/02/2012 lisbon...

Roberto Palmieri – Workshop on Distributed Transactional Memory(WDTM 2012) - 22/02/2012 Lisbon

Boosting STM Replication via Speculation

Roberto Palmieri, Paolo Romano, Francesco Quaglia, Luis Rodrigues

Replication

• Is a typical way to achieve Fault Tolerance

• Several techniques:– Primary Backup approach– Active Replication approach–…

Roberto Palmieri – Workshop on Distributed Transactional Memory (WDTM 2012) - 22/02/2012 Lisbon

Why Active Replication

• Each replica keeps all data and executes the same transactions in the same order

• PRO (+)– Full failure masking

– No coordination for processing read-only transactions

– Prone to target performance issues

• CONS (-)– Agreement on common execution order

– Deterministic business logic


APPROVED

Literature solutions for actively replicated transactional

systems


State Machine Approach (SM)

• Implements Active Replication paradigm• Based on Atomic Broadcast as GCS• Does not exploit any kind of optimism• Requires deterministic Local CC

Coordination phase

to-broadcast (m) to-delivery (m)

Processing m


Optimistic Approach (OPT)• Based on Optimistic Atomic Broadcast as GCS• It processes in optimistic manner:• At most one conflicting transaction• Any non-conflicting transactions

Coordination phase

to-broadcast (m) to-delivery (m)

Processing m

opt-delivery (m)

Optimistic processing of m


if(opt-delivery order == to-delivery order)

Commit(m)

if(opt-delivery order <> to-delivery order)

Abort & Restart(m)

if(m is non-conflicting transaction) Commit(m)

Critiques to OPT (1)

• A-priori knowledge on transaction read/write sets (to detect conflicts) might be infeasible (non-determinism)

• Unpredictability of transactions data access pattern imposes safe (over-) estimation of accessed data sets (reduced concurrency)


Unapproved

for

multico

res


• Limited overlapping in case of fine-grain transactions


Unapproved

for STM


• Ineffective if deployed on less or unpredictable networks– Networks without spontaneous ordering

of optimistic deliveries


Unapproved

for generic

network

s

Unbalancing RatioCoordination

delayLocal

Transaction Execution Time

Traditional Scenarios Modern (STM) Scenarios

≈ 2 msec

≈ 1/10 msec

≈ 2 msec

≈ 10/100 μsec

Long stall periods -> Resources underutilization


Target: Maximize the overlap

Coordination phase m1



to-broadcast (m1)

to-broadcast (m2)

to-broadcast (m3)

Opt-delivery (m1)

Opt-delivery (m2)Opt-delivery (m3)

……

to-delivery (m1)

to-delivery (m2)

to-delivery (m3)……


• Coordination delay Vs Local transaction processing• Local transaction processing Vs Local transaction

processing Multip

le o

r sam

eSeria

lizatio

n O

rders

How: Speculative Processing• Basic ideas:– Activate all transactions as soon as they are optimistic delivered– Explore (in depth and/or in breadth) multiple serialization orders

time

commit(T’B)TB:

TA:

opt-del(TB)opt-del(TA) to-del(TA) to-del(TB)

exec TB

TB->TA

exec TA

TA->TB

exec T’A

TB->TA

exec T’B

TA->TB

abort(T’A)abort(TB)commit(T

A)


Speculative Processing:desirable properties

• Correctness– The history of committed transaction generated is 1-copy

serializable

• Non-Redundancy– No two speculative instances of the same transaction

observe the same snapshot

• Completeness– Eventually, every permutation of optimistic delivered

transactions (not yet final delivered) that produces a distinct snapshot is explored


Relaxing completeness• The relevance of the completeness property

depends on the likelihood of mismatches between final and optimistic delivery orders

completenessmin. max.

AGGRO STRat-most onespeculative

order

every distinctspeculative order

OSARE some

“opportunistic”speculative orders


[SPAA2010][ISPA2010][SRDS 2011][NCA 2011]

✔ Completeness✗ Completeness✗ Completeness

Aggressively Optimistic Transaction Processing (AGGRO)

• Tailored for networks with spontaneous order• Lock based concurrency control• Optimized lock semantic to reduce the lock

wait time of conflicting transactions• No a priori knowledge on transactions

read/write sets• No sibling transactions (reduced overhead)


AGGRO: key ideas1. Uncommitted data item versions are

aggressively made visible to other transactions (upon transaction completion) independently of whether the creating transactions will be eventually committed

2. Speculative transactions guided to follow the Optimistic delivery order

The ordering relations based onTi → Tj

OPT


Data item version states• Each version of shared objects in the transactional memory

could be:– Committed

– Uncommitted

• Committed– The creator transaction has already committed

• Uncommitted– Work-In-Progress (WIP) state, the creator transaction has not

reached the complete stage yet

– Complete, the creator transaction has reached the complete stage, but is not finalized as committed or aborted yet


Transactions’ ordering• Two transaction lists:– Opt-Delivered transactions (ODL)

– TO (final)-Delivered transactions (FDL)

• Transaction Ti → Tj if

– Ti and Tj are both currently recorded within ODL, with Ti

ordered before Tj

– Ti is currently recorded within FDL, while Tj is currently

recorded within ODL

– Ti and Tj are both currently recorded within FDL, with Ti

ordered before Tj


Ti → Tj

OPT

Algorithm sketch: ReadRead dataitem X by Ti

Get version V according to →OPT

V is marked as WiP

Wait until the mark is

removed

Yes

No

Read V and update the read-form set of Ti


Algorithm sketch: Write

Write on dataitem X by Ti

The dataitem X is marked as WiP

Abort (and restart) all transactions that follow Ti (according to )

and read X from a different transaction

→OPT

Early abort mechanism


Algorithm sketch: Complete

Ti completes its execution

Remove all the WiP marks

Make available written dataitems to other speculative transactions

Permits to activate next conflicting transactions


Trace-based Simulator• A discrete event simulator based on JavaSim framework

• Realistic timing and data access patterns (coming from execution of JVSTM)

• (Optimistic) Atomic Broadcast service entails the possibility of batching messages to improve performance

• Atomic Broadcast average delays:– Optimistic delivery: 500 μsec

– Final (total ordered) delivery: 2 msec

• LAN environment with no mismatch between optimistic and final deliveries (spontaneous order)


Test bed

• Benchmarks:

Name Type Mean Transaction Execution Time

RB-Tree Micro Benchmark 77 μsec

SkipList Micro Benchmark 281 μsec

List Micro Benchmark 324 μsec


Simulation results• Baseline (OPT) Vs AGGRO

no speculation speculation

10x speedup


CPU Utilization


Simulation results• Baseline (OPT) Vs AGGRO

no speculation speculation


CPU Utilization


Thank you for the attention


roberto palmieri – workshop on distributed transactional memory (wdtm 2012) - 22/02/2012 lisbon...

Documents