Alternatives to Locks

1
Alternatives to Locks

• Presented by Isaac Charles 11/18/05

2
Outline

• Review locking techniques
• Review synchronization primitives
• Non-blocking algorithms
• Transactional Memory
• Software
• Contention Managers
• Hardware

3
Locking Techniques

• Coarse-Grained lock whole routine (ex Java
  synchronized)
• Fine-Grained lock only the needed item, perhaps
  hand-over-hand
• Optimistic find location, acquire lock, verify
  location. Two passes
• Lazy One pass. Mark then delete. Other
  processes lock then check marks. Data reads may
  return outdated information.

4
Problems With Locking

• Deadlock no progress
• Livelock no overall progress
• Priority Inversion lower-priority process
  preempted while holding lock
• Convoying lock-holder descheduled, no others
  may go
• Starvation a process never runs
• Very difficult to implement and debug

5
Synchronization Primitives
6
Compare and Swap

• atomic CompareAndSwap(location, oldval,
  newval)
• prev loc
• if(prev oldval)
• loc newval
• return prev
• // or return boolean for prev oldval

7
Non-Blocking Progress

• Wait-free all processes can complete operation
  in a finite number of steps, regardless of
  actions of other processes.
• Lock-free In the absence of interference, any
  process will make progress (liveness). Some
  thread will always make progress.
• Obstruction-free A process will complete an
  operation if it executes in isolation.

8
Lock-Free Algorithms (Example)
9
Performance Measurements
10
Problems With Locking (Review)

• Deadlock no progress
• Livelock no overall progress
• Priority Inversion lower-priority process
  preempted while holding lock
• Convoying lock-holder descheduled, no others
  may go
• Starvation a process never runs
• Very difficult to implement and debug

11
Implementation Problems

• Starvation hard to avoid
• Extremely difficult to implement
• A practical methodology should permit a
  programmer to design, say, a correct lock-free
  priority queue, without ending up with a
  publishable result. M. Herlihy
• ABA problem

12
Transactional Memory

• Steps (for each thread)
• Announce start of a transaction
• Execute operations on shared objects
• Attempt to commit the transaction
• If commit succeeds, operations take effect
• If commit fails, operations discarded (and may be
  retried)

13
Sample Transactional Code
open(mode) - throws Denied if state of other
opened items inconsistent release()

• beginTransaction()
• commitTransaction()
• abortTransaction()

14
Under the Hood

• When open() is called
• System verifies that all other open items (for
  the transaction) are in a consistent state
• If so, a copy is made of the object and returned.
• If not, throws Denied, so transaction will not
  continue needlessly
• When commitTransaction() is called, all open
  items must again be verified, then CAS() the
  transactions state

15
Keeping Track of Objects

• At open(), if transaction state is
• Committed new object is official copy
• Aborted old object is official copy
• Active contention

16
Contention Management

• Livelock is a risk with obstruction-free systems
• When a transaction calls open() on an already
  open item, what to do?
• Abort this transaction?
• Abort the other transaction?
• Contention Manager makes decision

17
Possible Contention Managers

• Aggressive always abort any other transaction
• Polite exponential pause before aborting our
  transaction. At some threshold, abort the other
  transaction
• Priority-based, possibly based on progress
• Greedy time-stamp based oldest transaction
  continues. Must have a recovery process when a
  transaction fails

18
Performance Results
19
Key Advantages

• Code looks like coarse-grained locking
• Easy to reason about correctness
• Often faster than coarse-grained locking
• Unmodified code could improve speed with hardware
  improvements
• Contention managers could be tuned to specific
  applications

20
Key Disadvantages

• Slower than fine-grained locking
• Implementations abound experimental

21
Alternative Uses

• Hardware Transactional Memory
• Transactional Lock Removal

22
Hardware Transactional Memory

• Use processor-local cache to implement
  transactions
• Need new instructions
• LT Load-transactional
• LTX Load-transactional-exclusive
• ST Store-transactional
• COMMIT Make transaction permanent
• ABORT Discard transaction
• VALIDATE Test transactions current status

23
Transactional Lock Removal

• Programs using locks run in a transactional way
  Transactional Lock Removal
• No software changes
• Use timestamps to resolve conflicts
• Requires hardware support

24
Sources

• R. Guerraoui, et al. Robust Contention
  Management in Software Transactional Memory. In
  Proceedings of SCOOL, Oct 2005 (not yet
  published).
• M. Herlihy and N. Shavit. Multiprocessor
  Synchronization and Concurrent Data Structures.
  To be published 2006.
• M. Herlihy and J. E. Moss. Transactional Memory
  Architectural Support for Lock-Free Data
  Structures. In Proceedings of the Twentieth
  International Symposium on Computer Architecture,
  pages 289-300, San Diego, CA, May 1993.
• M. Herlihy. Wait-Free Synchronization. ACM
  Trans. On Programming Languages and Systems, pp.
  124-149, January 1991.
• M. Herlihy. A Methodology for Implementing
  Highly Concurrent Data Objects. ACM Trans. On
  Programming Languages and Systems, pp. 745-770,
  Nov 1993.
• M. Herlihy, et al. Software Transactional Memory
  for Dynamic-Sized Data Structures. In
  Proceedings of the 22nd Annual ACM Symposium on
  Principles of Distributed Computing, pp. 92-101,
  July 2003.
• M. Herlihy, V. Luchangco, and M. Moir.
  Obstruction-Free Synchronization Double-Ended
  Queues as an Example. In Proceedings of the 23rd
  International Conference on Distributed Computing
  Systems, 2003.
• M. Michael and M. Scott. Simple, Fast, and
  Practical Non-Blocking and Blocking Concurrent
  Queue Algorithms. In Proceedings of 15th ACM
  Syposium on Principles of Distributed Computing,
  May 1996.
• R. Rajwar and J. Goodman. Transactional
  Lock-Free Execution of Lock-Based Programs. In
  Proceedings of the 10th International Conference
  on Architectural Support for Programming
  Languages and Operating Systems, Oct 2002.