Software Transactional Memory Should Not Be Obstruction-Free

1
Software Transactional Memory Should Not Be
Obstruction-Free

• Robert Ennals
• Presented by
• Abdulai Sei

2
Obstruction-Free

• Concept seen in previous paper by Maurice Herlihy
• A Methodology for Implementing Highly concurrent
  Data Objects
• Weakest of the series of properties
• wait-free - each process must complete an
  operation after taking a finite number of steps
• lock-free - a thread cannot lock up and every
  step it takes brings progress to the system
• obstruction-free - a thread is guaranteed to make
  progress when all other threads are suspended
• Essential in distributed systems (which is the
  background of most Software Transactional Memory
  researches)

3
Software Transactional Memory (STM) and
Obstruction-Freedom

• Obstruction-freedom is not a necessary property
  for STM in a non-distributed systems because
• use of STM is to improve performance of programs
  that would otherwise execute sequentially but
  with obstruction-freedom, this is a problem
• it is sometimes allowable for one transaction to
  block another transaction of the same or lower
  priority
• easy to adaptively vary the of task to match
  available cores
• unlikely that a transaction will be blocked by a
  transaction that has been switched out

4
Threads and Tasks

• Thread and Tasks
• thread a programmable level construct use to
  specify that several block of codes can be
  executed in parallel
• tasks (kernel thread) OS level construct that
  runs on a core and execute code from threads
• Use of threads
• threading for convenience can be ported to STM
  by converting all locks-protected blocks into
  transaction
• threading for performance large program that
  previously uses small of threads can now be
  broken down into small programs running on more
  threads

5
Application Parallelism

• critical to map application parallelism to
  underlining hardware parallelism and must be done
  carefully
• i.e. mapping kernel threads onto actual CPU
• building STM that tries to be immune to poor
  mapping does not solve the core problem

6
Motivation behind Obstruction-Freedom

• Prevent a long running transaction from blocking
  others transaction
• e.g a transaction computes for a year then
  write to the same thread. Need to block other
  threads for this to happen
• obstruction-freedom guarantee progress if there
  are no other conflicting transactions
• lock-freedom only guarantee that the system as a
  whole make progress
• Prevent system locking
• occurs when a thread switch part-way through a
  transaction
• but guarantee the thread will be switch back
  not a problem
• Prevent the system locking up if a thread fails

7
Why Obstruction-Freedom makes efficient
implementation difficult

• ObstructionFreedom makes efficient
  implementation difficult
• Cache-Locality
• Object metadata must be adjacent to object data
  for unlikely cache misses
• Excessive Active Transaction
• Active transaction should not exceed number of
  cores causing new transactions to wait for free
  core

8
Implementation

• Based on concept in previous slides
• Idea
• revocable two phase locking for writes
• transaction locks all objects that it writes
  until it terminates
• what about dead lock?
• optimistic concurrency control for reads
• logs versions that transaction reads from
• verifies that versions are the same as the ones
  read when it commits
• Memory layout
• public memory can be accessed by any
  transaction
• private memory accessed by only transaction
  owner

9
Memory Layout
10
Implementation (oobject, ttransaction)

• Writing an objects
• t must obtain an exclusive lock on o
• If os handle is a v
• t uses atomic CAS to replace v with a pointer to
  a new write descriptor
• last-version field of write descriptor field set
  to v
• working copy initialized to the current version
  of o data
• If os handle is a pointer to a write descriptor
  w
• t waits until the owning transaction, s, sets the
  handle to be a version number indication it is
  finished
• if t, timeout after some of cycle, and s is of
  lower priority, t request s aborts itself
• t can find descriptor for s by zeroing the
  lower-order bits of w
• What if deadlock is detected?

11
Implementation- continue

• Reading an object
• to read, t waits for o handler to be a version
  then logs the version number in the read
  descriptor
• Committing an object
• transaction checks that it is valid
• when is a transaction considered valid?
• then makes it write visible to other transactions

12
Performance
13
Performance Evaluation
14
Reasons for poor performance

• Obstruction-Freedom effect on cache and TLB
• due to the inability to colocate data and
  meta-data in memory such that they map to the
  same cache line
• affect performance in the uncontended case
• Helping
• applies to the contended case
• contending transaction help others to finish
• each transaction slows each other down as the
  number of transaction involve in helping increases

15
Conclusion

• Obstruction-freedom is not an important property
  for STMs
• Non-obstruction-freedom can achieve significantly
  better performance than an obstruction-free one
• Future designs should not attempt to be
  obstruction-free