Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Concurrency in Scala: from locks to STM

Concurrency in Scala: from locks to STM

Slides for the Scalawaw meetup presentation on Jun 28 2023

Michał Bednarz

June 28, 2023

More Decks by Michał Bednarz

Other Decks in Programming


  1. 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
  2. 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
  3. read-modify-write race condition lost update problem (write-write problem) - update

    done by a thread might be overwritten by another thread
  4. 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
  5. 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
  6. 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
  7. 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
  8. Problem with atomic variables Specific atomic operations are atomic. But

    composition of multiple atomic operations isn't atomic.
  9. Transactional Memory In-memory analogy to DB transactions Alternative to low-level

    thread synchronisation Ensures safe access to shared memory
  10. 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.
  11. 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.
  12. 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