STM and Structured Concurrency — The Battle with Multithreading Dragons
summary
Compares Java's traditional locks/synchronized to a custom extended-lock (an aspect-wrapped try-lock map) and Clojure-style STM refs by implementing a bank-transfer demo that deadlocks under naive locking and shows failures in roughly 1 in 100 runs across ~10,000 concurrent runs. Shows the extended-lock reduces some races but increases complexity and maintainability, while STM provides transactional safety with lower throughput and more consistent behavior; connects these trade-offs to upcoming structured-concurrency work in Java.
AI-written summary · about
chapters (16)
- 0:00Concurrency intro
- 8:23Multithreading sync needs
- 13:02Single object sync in Java
- 15:11Multi-object sync pitfalls
- 18:31Deadlock problem and avoidance
- 22:53Traditional sync limits
- 23:57AOP alternative
- 31:07Databases for concurrency
- 33:58STM introduction
- 36:47Java STM with Closure
- 38:55STM pros and cons
- 39:15Semaphores and phasers
- 42:10Structured concurrency hope
- 45:23Custom scopes and errors
- 47:54Future of structured concurrency
- 48:42Summary & Q&A
related talks
41mStructured Concurrency in Java: The What & Why
03h 29mConcurrency with Clojure
39mLet's talk concurrency
43mStructured Concurrency in Java - The What and the Why
47mUsing Java 8 Lambdas and Stampedlock to manage thread safety
48mHandling concurrent access to shared resources in Java
54mStructured Concurrency: Hierarchical Cancellation & Error Handling
02h 17mJava's Concurrency Journey Continues! Exploring Structured Concurrency and Scoped Values