Transactional Memory: Architectural support for Lock-Free Data - - PowerPoint PPT Presentation

Transactional Memory: Architectural Support for Lock-Free Data Structures

By Maurice Herlihy and J Eliot B. Moss 1993

Presented by Minh Truong PSU May, 2013 Slide content heavily borrowed from Ashish Jh and Steve Coward PSU SP 2010 and 2011 CS-510

Transactional Memory: Architectural support for Lock-Free Data Structure

By Maurice Herlihy and J. Eliot B. Moss 1993

Agenda

• Overview of Lock - Base
• Overview of Lock - Free synchronization techniques
• Transactional Memory

○ Usage, ○ Implementation, ○ Cache Line states ○ Processor Actions ○ Snoopy Cache Actions

• Simulations
• Benchmarks & results
• Summary

Lock - Based synchronization

• Mutual Exclusion - only one threads at a time can access critical section
• Pessimistic approach
• Easy to uses
• Doesn't scale well do to test-and-set
• Cause problems as priority inversion, convoying and deadlock.

Lock - Free Synchronization and improvements

• Non-blocking
• Optimistic Approach
• Uses Read-Modify-Write (RMW) operations such as Compare-And-Swap

(CAS) and LL&SC (Load link and Store Condition) ○ limited to operations on single-word or double-words

• Difficult program logic
• Doesn't have priority inversion, convoying and deadlock problems.

What kinds of Improvement can we do to Lock-Free synchronization?

• Keeps the positive aspect of lock-free like non-blocking, and doesn't have

issues such as priority inversion, convoying and deadlock.

• Allows RMW to operations on multiple, independently chosen words of

memory

• Easy program logic
• Provide Mutual Exclusion

This is where Transactional Memory comes in!!!

Transactional Memory

"A transaction is a finite sequence of machine instructions, executed by a single process satisfying" the two properties below. (quote from paper)

• With serializability and atomicity properties the assumption here is even though both

process can be running concurrently with every statements, only one process will be able to commit and the other will abort.

• Using these primitives

○

Programmer can define customized read-modify-write operations that operate on arbitrary regions of memory, not just with single words.

• Supporting non-transaction instruction, such as LOAD and STORE does not have any

effect on the transaction read and write set.

Transactional Memory

Primitive Instructions for Accessing Memory: Load-transactional(LT) - read value of shared memory location into private register Load-transactional-exclusive(LTX) - read value of shared memory location into private register and location to be updated. Store-transactional(ST)- write value from private register to shared memory location Primitive Instruction for manipulating transaction state: Commit (COMMIT) - make change permanent, Abort(ABORT) - discard all update to write set, Validate(VALIDATE) - test the current state.

• Intended to replace “short” critical section where there is no need to acquire lock,

execute critical section and release_lock.

• It satisfies Atomicity and Serializability properties.
• Intended for activities that access small number of memory location in primary memory.
• Run complete within single scheduling quantum and the number of locations accessed

not to exceed architecturally specified limit. Below is the code comparison between Transactional Memory and Non-block methods:

Usage

Implementation

Design satisfies following criteria

• In absence of transactional memory, Non-transactional operation uses same caches,

its control logic and coherency protocols ○ Otherwise uses two separate caches so traffic is isolated for non-transactional

• perations.
• Custom hardware support restricted to “primary caches” and instructions needed to

communicate with them

• Committing or Aborting a transaction is an operation “local” to the cache

○

Does not require communicating with other CPU’s or writing data back to memory Transactional Memory exploits cache states associated with the cache coherency protocol

• Available on Bus based (Goodman's snoopy protocol) or network-based (Chaiken

Directory protocol) architectures

• Cache State - could be in one the MESI (Modified, Exclusive, Shared, Invalid) states.
• SHARED - permitting READ when memory shared among all the processors.
• EXCLUSIVE - permitting WRITE but only exclusive to one processor.
• INVALID - not available to any processor.

BASIC IDEA

• Any protocol capable of detecting accessibility conflicts can also detect transaction

conflict at no extra cost.

• Implemented by modifying standard multiprocessor cache coherence protocols
• Apply this state logic with transaction counterparts
• If any transaction conflict detected - ABORT the transaction
• If transaction stalled - Use a timer or other sort of interrupt to abort the Tx

Cache Line States

• A dirty value “originally read” must either be write-back to memory,

○

• r set to XCOMMIT entry as its an “old” entry

■

this avoid continues writing back to memory which improve performance.

• Transaction requests REFUSED by BUSY response this transaction will aborts and retries

To prevents deadlock or continual mutual aborts Subject to starvation

• Every transaction operation takes 2 cache line entries

○

Transactional cache cannot be big due to performance considerations - single cycle abort/commit + cache management

○

Therefore, only short transaction size supported

Processor Actions

• Non-transactional operations behave as in Goodman's original protocol.
• If action was issued by an aborted transaction then it will cause no bus cycle and may

return arbitrary value.

• Other conditions for ABORT are interrupts and transaction cache overflow
• Commit does not force changes to memory it taken care of it (i.e. mem written) only

when critical section(CL) is evicted or invalidated by cache coherence protocol (?)

Snoopy Cache actions

• Tables shows the response to each of the requests on both regular

and transactional cache snoop on the bus.

• Either cache can issue a WRITE when it needs to replace a cache

line.

• Main memory responds to all L1 read misses
• If TSTATUS==FALSE, Transactional cache acts as Regular cache (for

NORMAL entries)

Simulations

• Bus-Based architecture (Goodman's snoopy protocol)
• Network-based architecture (Chaiken Directory Protocol)
• Used 32 processor
• Memory access (w/o contention) required 4 cycles.
• Network architecture used 2-stage network with wire and switch delay of 1 cycle

each.

• Each access to

regular or transaction cache, including commit and abort is a single cycle ○ reset transactional tag bits in parallel.

• Commit - not force

newly-committed entries back to

• memory. Instead it

replaced as they are evicted or invalidated by the ongoing cache coherence protocol.

• Software mechanisms

1) test-and-test-and-set(TTS) 2) spin locks with exponential backoff (MCS)

• Hardware mechanisms

1) LOAD_LINKED/STORE_COND (LL/SC) with exponential backoff (single-word counter benchmark, ran LL/SC directly on shared variable) 2) hardware queueing(QOSB) - incorporated into the cache coherence protocol

Counting Benchmark

• Each N processes

increments a shared counter 2^16/n times. N range from 1 to 32

• Two shared-memory

accesses, high contention

• In absence of

contention, TTS (same with SW & HW Queue) makes 5 references to mem for each increment ○ RD + test-and-set to acquire lock + RD and WR in CS

• TM requires only 3 mem

accesses ○ RD & WR to counter and then COMMIT(no bus cycle)

Counting Results

• LL/SC doesn't required commit operation and without using lock therefore it

perform the better.

Producer/Consumer Benchmark

• N processer share a bounded FIFO buffer.
• Half of the processors produce items and half consume items.
• 2^16 operations.

Producer/Consumer Benchmark Result

• Throughputs are flat for bus architecture network but transactional has higher

throughput than other.

• Because of increase contention throughput suffer for network architecture.

Transactional memory suffer less.

Doubly-Linked List Benchmark

• N processes share a

doubly-linked list with head and tail pointer.

• Each transaction

modifies head or tail but not both so one process can enqueues where it can't interference from

• ther dequeuing.
• When queue is empty

transaction must modify both head and tail which cause conflict.

• In lock-based algorithms

will cause problem if both head and tail are not lock.

• Transaction uses

VALIDATE to check for a pointer before dereference it.

Doubly - Linked List Result

• Lock-based algorithms throughput suffer because it doesn't allow enqueues and

dequeues overlap.

Summary

Transactional Memory Pros and Cons

Pros

• Easy to perform atomic updates of multiple independent memory words.
• exploiting cache-coherency mechanisms, and
• leveraging concept of Database Transactions
• Even in absence of priority inversion, convoying & deadlock
• uses no locks and so has fewer memory accesses
• Benchmark shows that it is outperforms other atomic update techniques.

Cons

• Transaction has to have short duration and small datasets. If Longer then will be

aborted by interrupts or synchronization conflict.

• For large dataset then larger transactional cache is needed where

synchronization conflict will occur.

• Needs more elaborate hardware mechanisms
• Rely on software-level adaptive backoff to space out conflicting transactions and

reduce abort rate.

• Weaker consistency model would require explicit barriers at start and end,

impacting performance