1 / 24

Alternatives to Locks

Alternatives to Locks. Presented by Isaac Charles 11/18/05. Outline. Review: locking techniques Review: synchronization primitives Non-blocking algorithms Transactional Memory Software Contention Managers Hardware. Locking Techniques.

imelda
Download Presentation

Alternatives to Locks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Alternatives to Locks Presented by Isaac Charles 11/18/05 Isaac Charles 11/18/05

  2. Outline • Review: locking techniques • Review: synchronization primitives • Non-blocking algorithms • Transactional Memory • Software • Contention Managers • Hardware Isaac Charles 11/18/05

  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. Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  5. Synchronization Primitives Isaac Charles 11/18/05

  6. Compare and Swap atomic CompareAndSwap(location, oldval, newval) { prev = loc; if(prev == oldval) { loc = newval; } return prev; // or return boolean for prev == oldval } Isaac Charles 11/18/05

  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. Isaac Charles 11/18/05

  8. Lock-Free Algorithms (Example) Isaac Charles 11/18/05

  9. Performance Measurements Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  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) Isaac Charles 11/18/05

  13. Sample Transactional Code open(mode) - throws Denied if state of other opened items inconsistent release() beginTransaction() commitTransaction() abortTransaction() Isaac Charles 11/18/05

  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 transaction’s state Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  18. Performance Results Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  20. Key Disadvantages • Slower than fine-grained locking • Implementations abound – experimental Isaac Charles 11/18/05

  21. Alternative Uses • Hardware Transactional Memory • Transactional Lock Removal Isaac Charles 11/18/05

  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 transaction’s current status Isaac Charles 11/18/05

  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 Isaac Charles 11/18/05

  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. Isaac Charles 11/18/05

More Related