Monday 25 February 2008

Reading 1. Basic Concepts and Design Space

February 22nd, 2008

Main Syntactic Construct



atomic {
x.Bar();
y = x.Baz(); // (1)
y.Foo();
}

atomic {
y = null; // (2)
}

TM system guarantees that code inside atomic blocks runs as if there are no other concurrent threads.
In the example, there is no data race between (1) and (2).
TM system should detect transaction memory conflicts and abort (and restart) one of the transactions.

Operational Semantics


Replace atomic with synchronized(MasterLock). The correct TM-system implementation should be equivalent.
Real-life system should do better!

TM is not a concurrent programming panacea:
bool flagA = false;
bool flagB = false;

// Th1:
atomic {
while(!flagA);
flagB = true;
}

// Th2
atomic {
flagA = true;
while(!flagB)
}

Th1 and Th2 deadlock! If we put smaller atomics, they will work.

Transaction Properties In TM System


TM-guaranteed properties:
Isolation - while transaction executes, no other transaction sees its changes, and vice versa.
Atomicity - transaction either does all changes it does to memory, or appears not to execute at all.
Not guaranteed:
Consistency - cannot be specified independently of a particular program

Exceptions


Exceptions thrown from inside atomic should commit transaction. Otherwise, complicated handling of exception object should be implemented.

Additional Features


retry - implementing conditional variables
atomic {
if (buffer.IsEmpty()) retry;
var value = buffer.GetFirst();
...
}

Will only work if sufficient progress guarantees are provided by TM system (wait freedom or lock freedom - see next lecture)

orElse

Weak Or Strong Isolation


Weak Isolation: transactions are only isolated from other transactions.
Strong Isolation: transactions are isolated from non-transactional code too (as if all memory accesses outide programmer-written atomics are surrounded in small atomics too)

Nested Transactions


Generally, when nested transaction commits, its changes are only seen by the parent transaction.

flattened nested transactions: aborting nested aborts its parent
closed nested transactions: abroting nested only aborts itself.

However, open nested transactions are useful.
open nested transactions: commit of nested open transaction is immediately seen by all.
Reduces conflicts (e.g. gensym())

Exceptions


Should commit transaction, otherewise non-trivial handling of exception object should be implemented.

No comments: