1 / 12

How I learned to stop worrying and love the lock

How I learned to stop worrying and love the lock. Rob Ennals Intel Research, Cambridge. Locks as an interface ≠ Locks as an implementation. Locks as a programming model – Bad Using locks in the back end – Sometimes good. Atomic ≈ One Big Fat Lock. An easy way to explain transactions

lumina
Download Presentation

How I learned to stop worrying and love the lock

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. How I learned to stop worrying and love the lock Rob Ennals Intel Research, Cambridge

  2. Locks as an interface ≠Locks as an implementation Locks as a programming model – Bad Using locks in the back end – Sometimes good

  3. Atomic≈One Big Fat Lock An easy way to explain transactions And often the best way to implement them

  4. Free of Locks ≠ Lock Free Lock freedom – a very useful concept But the name confuses the hell out of people

  5. No Deadlock ≠Lock Free No Deadlock or Livelock - Essential But often fine to wait for another transaction

  6. Respecting Priorities + Lock Free You can’t do both Should high priority transactions block others?

  7. Performance Matters Transactions aid parallelism => parallelism often for performance.

  8. Blocking Perf≥Non-Blocking Perf “blocking” means we allow blocking, not that we require blocking. Respecting priorities can also reduce performance.

  9. What do people actually need? • Non blocking? • Respecting priorities? • IO in transactions? • Nested transactions? Give the people what they want, but no more.

  10. Conclusions Sometimes Non-Blocking is nice But sometimes it isn’t Sometimes Non-Blocking is as efficient as Blocking But sometimes it isn’t Atomicity does not require non-blocking Don’t carry the bathwater round with the baby

  11. Backup Slides

  12. Atomic≈Several Smaller Locks With a smart compiler working out what to lock when Some designs may support priorities

More Related