The Performance of Spin Lock Alternatives for Shared-Memory Microprocessors

1. The Performance of Spin Lock Alternatives for Shared-Memory Microprocessors Thomas E. Anderson Presented by David Woodard

2. Introduction • Shared Memory Multiprocessors • Need to protect shared data structures (critical sections) • Often share resources including ports to memory (bus, network, etc.) • Challenge: Efficiently implement scalable, low latency mechanisms to protect shared data

3. Introduction • Spin Locks • One approach to protecting shared data on multiprocessors • Efficient on some systems, but greatly degrades performance on others

4. Multiprocessor Architecture • Paper focuses on two dimensions for design • Interconnect type (bus/multistage network) • Cache coherence strategy • Six Proposed Models • Bus: no cache coherence • Bus: snoopy write through invalidation cache coherence • Bus: snoopy write-back invalidation cache coherence • Bus: snoopy distributed write cache coherence • Multistage network: no cache coherence • Multistage network: invalidation based cache coherence

5. Mutual Exclusion and Atomic Operations • Most processors support atomic read/write operations • Test and Set Load the (old) value of lock Store TRUE in lock • If the loaded value is false, continue  else continue to try until lock is free (spin lock)

6. Test and Set in a Spin Lock • Advantages • Quickly gain access to lock when available • Works well on systems with few processors or low contention • Disadvantages • Slows down other processors (including the processor holding the lock!) • Shared resources are also used to carry out the test and set instructions • More complex algorithms to reduce the burden on resources increases latency in acquiring lock

7. Spin on Read • Intended for processors with per CPU coherent caches • Each CPU can spin testing the value of the lock in its own cache • If free, then send test and lock transaction • Problem • Nature of cache coherence protocols slow down process • More pronounced in systems with invalidation based policies

8. Why Quiescence is Slow for Spin on Read • When the lock is released its value is modified, hence all cached copies of it are invalidated • Subsequent reads on all processors miss in cache, hence generating bus contention • Many see the lock free at the same time because there is a delay in satisfying the cache miss of the one that will eventually succeed in getting the lock next • Many attempt to set it using TSL • Each attempt generates contention and invalidates all copies • All but one attempt fails, causing the CPU to revert to reading • The first read misses in the cache! • By the time all this is over, the critical section has completed and the lock has been freed again!

9. Performance

10. Quiescence Time for Spin on Read

11. Proposed Software Solutions • Based on CSMA (Carrier Sense Multiple Access) • Basic Idea: Adjust the length of time between attempts to access shared resource • Dynamically or Statically set delay? • When to delay? • After Spin on Read returns true, delay before setting • After every memory access  Better on models where Spin on Read generates contention

12. Proposed Software Solutions • Delay on attempted set • Reduces the number of TSLs thereby reducing contention • Works well when delay is short and there is little contention OR when delay is long and there is a lot of contention • Delay on every memory access • Works well on systems without per CPU caches • Reduces the number of memory accesses thereby reducing the number of read instructions

13. Length of Delay - Static • Advantages • Each processor is given its own “slot”; this makes it easy to assign priority to CPUs • Few empty slots = good latency; Few crowded slots = little contention • Disadvantages • Doesn’t adjust to environments prone to bursts • Processors with same delay that have conflict will always have conflict

14. Length of Delay - Dynamic • Advantages • Adjusts to evolving environments; increases delay time after each conflict (up to a ceiling) • Disadvantages • What criteria determine the amount of back off? • Long critical sections could keep increasing delay in some CPUs • Bound maximum delay: What if the bound is too high? Too low?

15. Proposed Software Solution - Queuing • Flag Based Approach • As CPU waits  Add to queue • Waiting CPUs spin on flag of processor ahead of it in the queue (different for each CPU) • No bus or cache contention • Queue assertion and deletion require locks • Not useful for small critical sections (such as queue operations!)

16. Proposed Software Solution - Queuing • Counter Based Approach • Each CPU does an atomic read and increment to acquire a unique sequence number • When a processor releases a lock it signals the processor with the next successive sequence number • Sets a flag in a different cache block unique to the waiting processor • Processor spinning on its own flag sees the change and continues (occurs invalidation and read miss cycles)

17. Proposed Software Solution - Queuing • Advantages • Separate flag locations in memory prevents saturation from multiple accesses • Especially useful for multistage networks (separate memory modules) • Disadvantages • Still not efficient for models without per processor caches  Requires memory access of one memory location • Increased lock latency due to increased instructions (increment counter, check location, zero location, set another location) • Preempting a process cause all processes behind it in the queue to wait • Can’t wait for multiple events

18. Results

19. Hardware Solutions: Network • Combining Networks • Combine requests to same lock (forward one, return other) • Combining benefit increases with increase in contention • Hardware Queuing • Blocking enter and exit instructions queue processes at memory module • Eliminate polling across the network • Goodman’s Queue Links • Stores the name of the next processor in the queue directly in each processor’s cache • Inform next processor asynchronously (via inter-processor interrupt?)

20. Hardware Solutions: Bus • Use additional bus with specific coherence policy • Additional die space? Separate clock speed for bus? • Read broadcast • When one processor reads a value which other processors also need, fill all caches with one read • Eliminates extended quiescence waiting periods due to pending reads • Monitor bus for test and set instructions • Prevents bus contention  If one processor performs the test and set instruction, it can share the result and other processors can abort their test and set instructions • Typically cache and bus controllers are not aware of instruction types; this information is handled by functional units (ex: ALUs) further down the pipeline

21. Conclusions • Traditional Spin Lock approaches are not affective for large numbers of processors • When contention is low, models borrowed from CSMA work well • Delay slots • When contention is high, queuing methods work well • Trades lock latency for more efficient/parallelized lock hand-off • Hardware approaches are very promising, but requires additional logic  Additional cost in die size and money to manufacture

22. Resources • Dr. Jonathan Walpole http://web.cecs.pdx.edu/~walpole/class/cs533/winter2008/home.html • Emma Kuo: http://web.cecs.pdx.edu/~walpole/class/cs533/winter2007/slides/42.pdf