Adaptive Locks Combining Transactions and Locks for efficient

Adaptive Locks: Combining Transactions and Locks for efficient Concurrency Takayuki Usui et all

Introduction. • Computing is more multi processor oriented. • Explicit multi threading is the most direct way to program parallel system (monitor style programming). • Flip side – – Interference between threads. – Hard to detect conditions such as deadlocks and races. – Hard to get fine grained critical sections and course grained critical sections reduces concurrency

Alternatives • Transactional Memory. • Advantages – Higher level programming model. No need to know which locks to acquire. – No need of fine grained delineation of critical sections. • Disadvantages – Livelocks, slower progress. – High Overhead.

Idea • Try to combine the advantages of locks and transactional memory. • How do the authors propose we do that? • Adaptive Locks

What are adaptive locks. • Synchronization mechanism combining locks and transactions. • Programmer can specify critical sections which are executed as either mutex locks or atomically as transactions.

How? atomic (l 1) { code } Is equivalent to atomic{ code } when executing in transactional mode or lock (l 1); code ; unlock(l 1).

How do we decide if it should run as a transaction or as a mutex lock. • • Let us throw out some terminology. Nominal contention. Actual contention. Transactional overhead.

Nominal Contention s. insert(10) Thread 1 Nominal Contention = 1 Acquire lock Cannot acquire lock void public synchronized insert(val) { s[size] = val; size++ } Wait s. insert(20) Thread 2

Actual Contention Atomic{ s. insert(10) } Thread 1 Actual Contention = 1 Starts first Tries to execute simultaneously //Thread 1 starts S[0] = 10; // Thread 2 tries at the same time and Aborts. Atomic{ s. insert(20) } Abort Thread 2

Transactional Overhead. • How much overhead is incurred when the critical section executes in transactional mode versus mutex mode.

How are these terms helpful • The authors use these concepts to dynamically calculate which mode the critical section should be executed in. • Wait. . Are locks and transactions interchangeable? • No they are not. . But we will discuss how with certain high level correctness criteria this can be handled.

Contributions of this paper. • Efficient and effective implementation of adaptive locks. – Trading some accuracy to make it faster and reduce overhead. • Define conditions under which transaction and mutex locks exhibit equivalent behavior. • Evaluate adaptive locks with micro and macro benchmarks.

Programming with adaptive locks • Adaptive locks introduce syntax for a labeled atomic sections. al_t lock 1; atomic (lock 1){ // critical section }

Some rules for using adaptive locks • Programmer has the burden to make sure that if all the instances of atomic(lock 1) are replaced by mutex blocks (mutex mode) then the program is still correct. • Programmer also has the burden to make sure that if all the critical sections are executed as transactions (transactional mode) then the program still runs correctly.

More rules. . • All critical sections associated with the same lock should execute in the same mode. • Mode of nested adaptive lock should be the same as that of the surrounding lock. • Mode switching can also be done either for correctness (I/O operations = mutex mode) or for performance.

Cost benefit analysis • Remember the terms that we talked about before – Nominal Contention – Actual Contention – Transactional Overhead • The authors use these terms to come up with the decision making logic.

And the winner is a. o >= c • If this inequality holds then mutex mode is preferable. • All these factors are computed separately for all of the locks dynamically.

Implementation and Optimizations • Extension of the C language. • Compiler translates it into 2 object code versions. One for mutex version and one for transactional version. • Adaptive locks replace regular lock acquisition. • The adaptive lock state is packed into a memory word.

What is contained in the state • Number of threads executing in transactional mode = thrds. In. Stm. Mode • Whether lock is in mutex mode = mutex mode • Whether mutex lock is held = lockheld • Whether we are currently in the process of changing modes = transition.

int acquire(al_t* lock) { int spins = 0; Acquire is the main routine int use. Transact = 0; INC(lock->thds. Blocked); while (1) { intptr_t prev, next; prev = lock->state; if (transition(prev) == 0) { if ((use. Transact = transact. Mode(lock, spins))) { if (lock. Held(prev) == 0) { next = set. Mutex. Mode(prev, 0); next = set. Thrds. In. Stm. Mode(next, thrds. In. Stm. Mode(next)+1); if (CAS(lock->state, prev, next) == prev) break; } else { next = set. Mutex. Mode(prev, 0); next = set. Transition(next, 1); CAS(lock->state, prev, next); } } else { if (lock. Held(prev) == 0 && thrds. In. Stm. Mode(prev) == 0) { next = set. Mutex. Mode(prev, 1); next = set. Lock. Held(next, 1); if (CAS(lock->state, prev, next) == prev) break; } else if (mutex. Mode(prev) == 0) { next = set. Mutex. Mode(prev, 1); next = set. Transition(next, 1); CAS(lock->state, prev, next); } } } else { if (mutex. Mode(prev) == 0) { if (lock. Held(prev) == 0) { use. Transact = 1; next = set. Thrds. In. Stm. Mode(prev, thrds. In. Stm. Mode(prev)+1); next = set. Transition(next, 0); if (CAS(lock->state, prev, next) == prev) break; } } else { if (lock. Held(prev) == 0 && thrds. In. Stm. Mode(prev) == 0) { use. Transact = 0; next = set. Lock. Held(prev, 1); next = set. Transition(next, 0); if (CAS(lock->state, prev, next) == prev) break; } } if (spin_thrld < ++spins) Yield(); } /* end while(1) */ DEC(lock->thds. Blocked); return use. Transact; }

Performance Optimizations • Threads need to update variables that keep count and calculate the various statistics for adaptive reasoning. • Remember a (actual contention). • Instead of updating it all the time, threads do regular writes to it. Then a shared update changes the global value. • Of course this can give rise to write-write races but the authors seem to believe that sporadic inaccuracies in the statistics are not significant. • Also to note, inaccuracies in statistics will not result in wrong program execution but choosing the other mode to execute the critical sections.

Performance Optimizations contd. . • Atomic increment and decrement of variable locks->thds. Blocked is also avoided. • The atomic increment and decrement of this variable is done only if there is real spinning else it is not done. This is contrary to the earlier code which was shown.

Performance Optimizations contd. . int acquire(al_t* lock) { int spins = 0; . . . INC(lock->thds. Blocked); while (1) {. . . // try to acquire, // break if successful if (spin_thrld < ++spins) Yield(); } DEC(lock->thds. Blocked); . . . } int acquire(al_t* lock) { int spins = 0; . . . while (1) {. . . // try to acquire, // break if successful if (spins == 0) INC(lock->thds. Blocked); if (spin_thrld < ++spins) Yield(); } if (0 < spins) DEC(lock->thds. Blocked); . . . }

Performance Optimizations contd. . • o (optimization overhead) depends on shared memory updates. • To keep the estimate of o realistic but inexpensive, – It is calculated at regular intervals. – The number of accesses to memory for that transaction are noted and multiplied with a static estimate of much each transaction would take.

Reality Check. . • But hey is interchanging between locks and transactions legal. Are they equivalent? • Answer: No, they are not equivalent. • To be more specific, it depends on the type of STM system. TL 2 which is the STM used by the authors differentiates between locks and transactions when they are used interchangeably.

No more boring bullets. We are not MBA students Thread 2 commits but Thread 1 commits and It removes the first item. By that time, r 1 and r 2 Will see stale values. Does not copy the value to memory Thread 2 eventually Update the value

So how can we fix this • We can make a simple observation from this which is that there should be a lock for all the shared memory locations. • Every access to these locations should be done with the lock held. • This is the standard lockset wellformedness criteria for multi threaded programs.

Some results • Tested with micro and macro benchmarks • Tested with red black trees (STM), splay trees (mutex locks), fine grained hash tables – adaptive locks were as good as the better concurrency mechanism. • Tested with (Stanford Transactional Applications for Multi-Processing).

Questions?