Concurrency in Scala: from locks to STM

Slides for the Scalawaw meetup presentation on Jun 28 2023

Transcript

1. From locks to STM Concurrency in Scala
2. visibility because of different CPU cache layers (L1, L2, L3) - thread writes are not instantly visible to other threads by default. solved by volatile or synchronized compiler and CPU optimisations JIT compiler reordering. out-of-order execution. order of processor write buffer flush. solved by volatile or synchronized race conditions multiple threads are competing over the same resource when order of the access is significant. solved by synchronized or volatile + CAS Problems in concurrent programs
3. race condition critical section thread-safety when output of a concurrent program is non-deterministic because it depends on execution schedule of threads region of code concurrently modified by multiple threads when code or data structure is free from race conditions in a multithreaded program
4. read-modify-write race condition lost update problem (write-write problem) - update done by a thread might be overwritten by another thread
5. check-then-act race condition
6. pessimistic approach optimistic approach assume there'll be no conflict if conflict happens - retry acquire exclusive lock access the resource ensuring thread safety of critical sections
7. Pessimistic locking on the JVM synchronized java.util.concurrent.Locks fairness parameter tryLock() lockInterruptibly() doesn't support fairness thread is blocked when can't get access blocked thread can't be interrupted
8. Granularity in pessimistic locking coarse-grained fine-grained one lock for multiple objects problem: contention one lock per object problem: need to acquire locks in order
10. coarse-grained lock
11. fine-grained lock
13. Mutex synchronized in the cats-effect world non-reentrant lock for fibers
14. When to use pessimistic locking in a high-contention scenario. when it's very likely that multiple threads will enter critical section at the same time
15. Optimistic locking on the JVM atomic variables volatile variable + Compare And Swap
16. Ref thread-safe shared state in cats-effect world referentially transparent wrapper for AtomicReference
17. Ref try updating once
18. Ref update with retries
19. Ref decide yourself with access
20. Optimistic locking deadlock & starvation freedom. use in low-contention scenario. when retries are inexpensive
21. Problem with atomic variables Specific atomic operations are atomic. But composition of multiple atomic operations isn't atomic.
23. Transactional Memory In-memory analogy to DB transactions Alternative to low-level thread synchronisation Ensures safe access to shared memory
24. Transactional Memory A - atomicity C - consistency I - isolation D - durability
25. we're looking for the following semantics: commit starts memory transaction. It ensures block of code will run in isolation.
26. Optimistic STM commit statement maintains a log of read and write operations. At the end of commit block - all the writes are committed. In case of transactional conflict - the transaction is rolled back. Transaction is completed if it was committed or rolled-back and re-executed.
27. STM implementations in Scala ScalaSTM cats-stm ZIO stm
28. cats-stm Transactions can be rolled back and retried - so they can't be used with effects. Transactions can only be composed with other transactions and pure computations.
29. Transactional variable Transactional read/write access to a single memory location
30. abort / raiseError
31. retry
32. check
33. check with side-effects
35. STM runtime concurrency factor how many concurrent transactions are allowed? choose low number if contention is high chose higher number for logic with low contention concurrency factor is set to 4 by default
37. Transactional wrappers TMVar (Option) TSemaphore (simple counter) TQueue (immutable queue)
38. linktr.ee/mbednarz