Module 11: "Synchronization"
  Lecture 23: "Barriers and Speculative Synchronization"
 

How does it work?

  • Speculative locks
    • Every processor comes to the critical section and tries to acquire the lock
    • One of them succeeds and the rest fail
    • The successful processor becomes the safe thread
    • The failed ones don’t retry but venture into the critical section speculatively as if they have the lock; at this point a speculative thread also takes a checkpoint of its register state in case a rollback is needed
    • The safe thread executes the critical section as usual
    • The speculative threads are allowed to consume values produced by the safe thread but not by the sp. threads
    • All stores from a speculative thread are kept inside its cache hierarchy in a special “speculative modified” state; these lines cannot be sent to memory until it is known to be safe; if such a line is replaced from cache either it can be kept in a small buffer or the thread can be stalled
  • Speculative locks (continued)
    • If a speculative thread receives a request for a cache line that is in speculative M state, that means there is a data race inside the critical section and by design the receiver thread is rolled back to the beginning of critical section
    • Why can’t the requester thread be rolled back?
    • In summary, the safe thread is never squashed and the speculative threads are not squashed if there is no cross-thread data race
    • If a speculative thread finishes executing the critical section without getting squashed, it still must wait for the safe thread to finish the critical section before committing the speculative state (i.e. changing speculative M lines to M); why?
  • Speculative locks (continued)
    • Upon finishing the critical section, a speculative thread can continue executing beyond the CS, but still remaining in speculative mode
    • When the safe thread finishes the CS all speculative threads that have already completed CS, can commit in some non-deterministic order and revert to normal execution
    • The speculative threads that are still inside the critical section remain speculative; a dedicated hardware unit elects one of them the lock owner and that becomes the safe non-speculative thread; the process continues
    • Clearly, under favorable conditions speculative synchronization can reduce lock contention enormously