- dining philosophers problem - many threads accessing the same memory lead to problems like deadlock / livelock
- locks? hard to think about, don’t compose, priority inversion
- thread-safe hash table doesn’t mean you can atomically move an entry from one hash table to another
- transactions in memory! ACI from ACID (memory isn’t durable)
- transactional memory does compose!
- but wait, rolling back a transaction can get really expensive, how is this a benefit?
- only allowed to perform operations that can be rolled back / undone
- Haskell already does this in the type system, non-issue there
- optimistic concurrency
- no work completed while waiting for a lock
- work is done but may be discarded with TM
Last active
October 4, 2018 17:05
-
-
Save shapr/5d76a85ee9cae709bbc00d2876fa17df to your computer and use it in GitHub Desktop.
transactional memory lightning talk
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment