Transactional Memory

Software

• Locks do not compose because they can reach dead locks.
• supported features:
  • conflict detection
  • roll back
  • version control
  • contention management / conflict resolution

Nesting

• flattened
  • ignore the inner transaction
  • treat the inner transaction as the outer transaction
  • if the inner transaction fails then the outer transaction fails
• closed nesting
  • same as flattened
  • inner transaction can roll back
• opened nesting
  • transactions can have side affects visible to other threads
  • not a normal transaction model
  • will not be rolled back

Interactions with Non-Transactional Code

• software transactional memory requires that programmers be careful accessing transactional memory outside of transactions from different threads

Commits

• software transactional memory:
  • two-face locking???
  • acquire a global lock at the end of the transaction
• hardware transaction memory:
  • cache coherence protocol (has read write ownership)
    • can be used for version management
    • allows hardware transactional memory to be implemented

Concurrency

• sequential overhead: the time it takes for acquiring locks, etc… before actually performing read / writes

Terms

• pessimistic locking
• optimistic locking
• performance pathologies

Hardware

Motivation

• lock-based synchronizations
  • are coarse-grained but are hard to write and have poor scalability
• truly atomic

Interface

• RTM (relational transactional memory)
• Uses the cache line with bits for tracking if data has been changed or touched by other processes. In such a case the transaction will abort.

Abort

• caused by:
  • data conflicts
  • write to cache line
  • system calls

Interactions with Non-Transactional Code

• use lock for non-transactional memory
  • a single global lock (1 word)
  • determine if another thread is using the lock (test the locks)
  • the transactions should check if the lock is set