Speculative Lock Elision: Enabling Highly Concurrent Multithreaded Execution

1
Speculative Lock ElisionEnabling Highly
Concurrent Multithreaded Execution

• by
• Ravi Rajwar and James R. Goodman
• presented by
• Nathan Sadler

2
Motivation

• Many programs use locks for synchronization
• Many locks are not necessary
• Stores occur rarely during execution
• Updating different parts of data structure
• Locks generally undo previous operations

3
Atomicity

• If atomicity is maintained, all locks can be
  removed
• Conditions for atomicity
• Data read is not modified until critical section
  is complete
• Data written is not accessed until critical
  section is complete

4
Removing a Lock

1. Predict lock unnecessary
2. Speculatively execute critical section
3. If atomicity violated, recover
4. If atomicity not violated, commit

5
Important Considerations

• Only retry eliding lock until restart threshold,
  to avoid livelock
• Only one level of nested locks elided
• Memory consistency not affected
• All speculative operations atomic

6
Implementation

• Filter to select SLE candidates
• Maintain speculative register state
• ROB or checkpoint
• Speculatively retire instructions
• Maintain speculative memory state
• Write buffer
• Snoop write buffer after critical section commits

7
Implementation (cont.)

• Detect atomicity violations
• Utilize cache coherence
• Snoop cache access bit on external accesses if
  needed
• Flash clear on mispredict
• Resource constraints
• Recover or execute lock

8
Percentage Elided
9
Execution Time
10
Questions?

• How would this perform with commercial workloads?
• Is a completely hardware-based approach best?
• Would this cause too much confusion for program
  optimizers?