Concurrency: It’s Harder (and Easier) Than You Think
summary
Shows that unsynchronized Java can print answer becomes 0 or spin forever because the CPU/memory model can reorder stores and loads. Demonstrates a real-world surprise: SimpleDateFormat not thread-safe and an elusive ScalaMock race that tests rarely catch. Replaces reduce with fold in Clojure to get a 3.2x speedup on a 4-core Mac. Builds an Akka actor cache with a supervisor restart strategy to tolerate crashes and keep the system running.
AI-written summary · about
chapters (22)
- 0:00Start
- 3:13Memory Model
- 4:40Quiz
- 6:00The Memory Model
- 7:50The Nautical Crisis
- 9:08Instruction Level Parallelism
- 11:24The Elephant in the Room Testing
- 12:41Concurrency Bug in Scala
- 13:32Bordered Handlers
- 14:12Concurrency Bug
- 16:53Bottom Line Is Multi-Threaded Programming Is Hard
- 17:37Functional Programming
- 18:46Guaranteed Threadsafe Shared Mutable Data Structures
- 21:49Criterium
- 30:11Why Does this Make Concurrency So Much Easier
- 31:08Buggy Cash
- 32:03Receive Method
- 34:39Bugs
- 36:00Supervisor Strategy
- 36:40Null Pointer Exception
- 38:32It's Impossible To Write Really Reliable Software if You Write Sequential Code
- 41:06Father of Object-Oriented Software Development
related talks
44mConcurrency in Scala and on the JVM
39mLet's talk concurrency
50mThe Hidden Art of Thread-Safe Programming: Exploring java.util.con...
27mThe Mutability Matrix of Pain
03h 29mConcurrency with Clojure
45mThe Hidden Art of Thread-Safe Programming: Exploring java.util.concurrent
36mConcurrency — Java Memory Model — Not Just for Eagles
33mConcurrency for !Dummies (Who Don't Get It (...Yet))