Alternatives to Locks

Isaac Charles 11/18/05 1

Alternatives to Alternatives to LocksLocks

Presented by Isaac Charles Presented by Isaac Charles 11/18/0511/18/05


OutlineOutline

• Review: locking techniquesReview: locking techniques• Review: synchronization primitivesReview: synchronization primitives• Non-blocking algorithmsNon-blocking algorithms• Transactional MemoryTransactional Memory

– SoftwareSoftware– Contention ManagersContention Managers– HardwareHardware


Locking TechniquesLocking Techniques

• Coarse-Grained: lock whole routine Coarse-Grained: lock whole routine (ex: Java ‘synchronized’)(ex: Java ‘synchronized’)

• Fine-Grained: lock only the needed Fine-Grained: lock only the needed item, perhaps hand-over-handitem, perhaps hand-over-hand

• Optimistic: find location, acquire lock, Optimistic: find location, acquire lock, verify location. Two passesverify location. Two passes

• Lazy: One pass. Mark then delete. Lazy: One pass. Mark then delete. Other processes lock then check Other processes lock then check marks. Data reads may return marks. Data reads may return outdated information. outdated information.


Problems With LockingProblems With Locking

• Deadlock – no progressDeadlock – no progress• Livelock – no Livelock – no overalloverall progress progress• Priority Inversion – lower-priority Priority Inversion – lower-priority

process preempted while holding lockprocess preempted while holding lock• Convoying – lock-holder descheduled, Convoying – lock-holder descheduled,

no others may gono others may go• Starvation – a process never runsStarvation – a process never runs• Very difficult to implement and debugVery difficult to implement and debug


Synchronization Synchronization PrimitivesPrimitives


Compare and SwapCompare and Swap

atomic CompareAndSwap(location, oldval, atomic CompareAndSwap(location, oldval, newval) { newval) {

prev = loc;prev = loc;

if(prev == oldval) {if(prev == oldval) {

loc = newval;loc = newval;

}}

return prev;return prev;

// or return boolean for prev == oldval// or return boolean for prev == oldval

}}


Non-Blocking ProgressNon-Blocking Progress

• Wait-free – all processes can complete Wait-free – all processes can complete operation in a finite number of steps, operation in a finite number of steps, regardless of actions of other processes.regardless of actions of other processes.

• Lock-free – In the absence of Lock-free – In the absence of interference, any process will make interference, any process will make progress (“liveness”). Some thread will progress (“liveness”). Some thread will always make progress.always make progress.

• Obstruction-free – A process will Obstruction-free – A process will complete an operation if it executes in complete an operation if it executes in isolation.isolation.


Lock-Free Algorithms Lock-Free Algorithms (Example)(Example)


Performance Performance MeasurementsMeasurements


Problems With Locking Problems With Locking (Review)(Review)

• Deadlock – no progressDeadlock – no progress• Livelock – no Livelock – no overalloverall progress progress• Priority Inversion – lower-priority Priority Inversion – lower-priority

process preempted while holding lockprocess preempted while holding lock• Convoying – lock-holder descheduled, Convoying – lock-holder descheduled,

no others may gono others may go• Starvation – a process never runsStarvation – a process never runs• Very difficult to implement and debugVery difficult to implement and debug


Implementation Implementation ProblemsProblems

• Starvation hard to avoidStarvation hard to avoid• ExtremelyExtremely difficult to implement difficult to implement

““A practical methodology should A practical methodology should permit a programmer to design, say, permit a programmer to design, say, a correct lock-free priority queue, a correct lock-free priority queue, without ending up with a without ending up with a publishable result.” – M. Herlihypublishable result.” – M. Herlihy

• ABA problemABA problem


Transactional MemoryTransactional Memory

Steps (for each thread):Steps (for each thread):• Announce start of a transactionAnnounce start of a transaction• Execute operations on shared objectsExecute operations on shared objects• Attempt to commit the transactionAttempt to commit the transaction

– If commit succeeds, operations take If commit succeeds, operations take effecteffect

– If commit fails, operations discarded If commit fails, operations discarded (and may be retried)(and may be retried)


Sample Transactional Sample Transactional CodeCode

beginTransaction()beginTransaction()

commitTransaction()commitTransaction()

abortTransaction()abortTransaction()

open(mode)open(mode)- - throws Denied if state of other throws Denied if state of other opened items inconsistentopened items inconsistent

release()release()


Under the HoodUnder the Hood

• When open() is called:When open() is called:– System verifies that all other open items System verifies that all other open items

(for the transaction) are in a consistent (for the transaction) are in a consistent statestate

– If so, a If so, a copycopy is made of the object and is made of the object and returned.returned.

– If not, throws Denied, so transaction will If not, throws Denied, so transaction will not continue needlesslynot continue needlessly

• When commitTransaction() is called, all When commitTransaction() is called, all open items must again be verified, then open items must again be verified, then CAS() the transaction’s stateCAS() the transaction’s state


Keeping Track of ObjectsKeeping Track of Objects

At open(), if transaction state is:At open(), if transaction state is:– Committed: new object is official copyCommitted: new object is official copy– Aborted: old object is official copyAborted: old object is official copy– Active: contentionActive: contention


Contention ManagementContention Management

• Livelock is a risk with obstruction-Livelock is a risk with obstruction-free systemsfree systems

• When a transaction calls open() on When a transaction calls open() on an already open item, what to do?an already open item, what to do?– Abort this transaction?Abort this transaction?– Abort the other transaction?Abort the other transaction?

• Contention Manager makes decisionContention Manager makes decision


Possible Contention Possible Contention ManagersManagers

• Aggressive: always abort any other Aggressive: always abort any other transactiontransaction

• Polite: exponential pause before aborting Polite: exponential pause before aborting our transaction. At some threshold, abort our transaction. At some threshold, abort the other transactionthe other transaction

• Priority-based, possibly based on progressPriority-based, possibly based on progress• Greedy: time-stamp based – oldest Greedy: time-stamp based – oldest

transaction continues. Must have a transaction continues. Must have a recovery process when a transaction failsrecovery process when a transaction fails


Performance ResultsPerformance Results


Key AdvantagesKey Advantages

• Code looks like coarse-grained lockingCode looks like coarse-grained locking• Easy to reason about correctnessEasy to reason about correctness• Often faster than coarse-grained Often faster than coarse-grained

lockinglocking• Unmodified code could improve speed Unmodified code could improve speed

with hardware improvementswith hardware improvements• Contention managers could be tuned Contention managers could be tuned

to specific applicationsto specific applications


Key DisadvantagesKey Disadvantages

• Slower than fine-grained lockingSlower than fine-grained locking• Implementations abound – Implementations abound –

experimentalexperimental


Alternative UsesAlternative Uses

• Hardware Transactional MemoryHardware Transactional Memory• Transactional Lock RemovalTransactional Lock Removal


Hardware Transactional Hardware Transactional MemoryMemory

• Use processor-local cache to Use processor-local cache to implement transactionsimplement transactions

• Need new instructions:Need new instructions:– LTLT Load-transactionalLoad-transactional– LTXLTX Load-transactional-exclusiveLoad-transactional-exclusive– STST Store-transactionalStore-transactional– COMMITCOMMIT Make transaction permanentMake transaction permanent– ABORTABORT Discard transactionDiscard transaction– VALIDATEVALIDATE Test transaction’s current Test transaction’s current

statusstatus


Transactional Lock Transactional Lock RemovalRemoval

• Programs using locks run in a Programs using locks run in a transactional way – “Transactional transactional way – “Transactional Lock Removal”Lock Removal”

• No software changesNo software changes• Use timestamps to resolve conflictsUse timestamps to resolve conflicts• Requires hardware supportRequires hardware support


SourcesSourcesR. Guerraoui, et al. Robust Contention Management in Software Transactional R. Guerraoui, et al. Robust Contention Management in Software Transactional

Memory. In Memory. In Proceedings of SCOOLProceedings of SCOOL, Oct 2005 (not yet published)., Oct 2005 (not yet published).M. Herlihy and N. Shavit. M. Herlihy and N. Shavit. Multiprocessor Synchronization and Concurrent Data Multiprocessor Synchronization and Concurrent Data

Structures.Structures. To be published 2006. To be published 2006.M. Herlihy and J. E. Moss. Transactional Memory: Architectural Support for Lock-M. Herlihy and J. E. Moss. Transactional Memory: Architectural Support for Lock-

Free Data Structures. In Free Data Structures. In Proceedings of the Twentieth International Symposium Proceedings of the Twentieth International Symposium on Computer Architecture, on Computer Architecture, pages 289-300, San Diego, CA, May 1993.pages 289-300, San Diego, CA, May 1993.

M. Herlihy. Wait-Free Synchronization. M. Herlihy. Wait-Free Synchronization. ACM Trans. On Programming Languages ACM Trans. On Programming Languages and Systemsand Systems, pp. 124-149, January 1991., pp. 124-149, January 1991.

M. Herlihy. A Methodology for Implementing Highly Concurrent Data Objects. M. Herlihy. A Methodology for Implementing Highly Concurrent Data Objects. ACM ACM Trans. On Programming Languages and SystemsTrans. On Programming Languages and Systems, pp. 745-770, Nov 1993., pp. 745-770, Nov 1993.

M. Herlihy, et al. Software Transactional Memory for Dynamic-Sized Data Structures. M. Herlihy, et al. Software Transactional Memory for Dynamic-Sized Data Structures. In In Proceedings of the 22Proceedings of the 22ndnd Annual ACM Symposium on Principles of Distributed Annual ACM Symposium on Principles of Distributed ComputingComputing, pp. 92-101, July 2003., pp. 92-101, July 2003.

M. Herlihy, V. Luchangco, and M. Moir. Obstruction-Free Synchronization: Double-M. Herlihy, V. Luchangco, and M. Moir. Obstruction-Free Synchronization: Double-Ended Queues as an Example. In Ended Queues as an Example. In Proceedings of the 23Proceedings of the 23rdrd International Conference International Conference on Distributed Computing Systems, 2003.on Distributed Computing Systems, 2003.

M. Michael and M. Scott. Simple, Fast, and Practical Non-Blocking and Blocking M. Michael and M. Scott. Simple, Fast, and Practical Non-Blocking and Blocking Concurrent Queue Algorithms. In Concurrent Queue Algorithms. In Proceedings of 15Proceedings of 15thth ACM Syposium on Principles ACM Syposium on Principles of Distributed Computingof Distributed Computing, May 1996., May 1996.

R. Rajwar and J. Goodman. Transactional Lock-Free Execution of Lock-Based R. Rajwar and J. Goodman. Transactional Lock-Free Execution of Lock-Based Programs. In Programs. In Proceedings of the 10Proceedings of the 10thth International Conference on Architectural International Conference on Architectural Support for Programming Languages and Operating SystemsSupport for Programming Languages and Operating Systems, Oct 2002., Oct 2002.

Documents

Alternatives to Locks