The talk was given by Dr. Roland Kuhn, and Viktor Klang.
Started with the definition on the concurrency, as a triangle:
Threads and locks
– The good: mapped onto CPUs, no overhead, high degree of control, and debugging (e.g., stack traces and you know where you at).
– The bad: Heavyweight, misuse, diminishing return (no linear scalability), high wake-up latency, barebones, and how to recover from failure.
– The ugly: treadsafe, defensive error handling.
Good: configurable execution, M:N task to thread ratio.
Bad: handling errors, dealing with block code, closing over mutable state.
Ugly: callback hell, composing results of the callbacks, low reusability, the question is your code is async or async (one or multiple threads?), and debugging is awful.
STM: Software transaction memory
Good: Typesafe and non blocking, transaction.
Bad: Transactions can crash with others and the size of failure ratio.
Ugly: Dealing with side-effects, failure, unpredictable performance, and debugging.
Good: configurable execution, type safe.
Bad: blocking composition, guesstimation of deadlock, and futures are one-offs.
Ugly: Cancel other’s futures. non-blocking requires polling, dealing with failure.
Conclusion: Stands between coordinaiton and execution and does help you with compartmentalisation.
Good: Typesafe, non-blocking composition, monadic, freely sharable, and failure recovery.
Bad: defers failure to downstream, closing over mutable state, no ordering of callbacks, and futures are one-offs.
Ugly: callback hell, debugging.
Conclusion: almost a balance proposal between triangle nodes.
Good: Typesafe, non blocking composition, declarative, deterministic (doesn’t matter where you run it, for the same input you will get the same output), and non-local composition.
Bad: CPS plugin error messages. limited applicability (error handling), debugging.
Ugly: CPS error messages.
Conclusion: Goes into the middle of the triangle og compartmentalisation, coordination and execution.
Good: Typesafe, non-blocking composition, declarative, more efficient in terms of memory allocation.
Bad : Limited applicability.
Ugly: Error handling.
Conclusion: Local and async and goes into the middle of the triangle.
Threads and queues
Good: Typesafe (The queue that you put between threads), blocking or non-blocking.
Bad: Heavyweight, scare, diminishing, high wake-up latency, and not really high-level, and no means for the recovery.
Ugly: Still we have a problem on where to put the errors, communication is unidirectional.
Conclusion: Between coordination and towards execution.
Good: Encapsulation, supervision to deal with failure, configurable execution, location transparency, models real-world, and requires less guarantees compare to the prior models.
Bad: Untypes, explicit lifecycle management, debugging.
Ugly: easy encapsulation violation to others, composition.
Conclusion: More focused on compartmentalisation.
Rx & friends
Good: Typesafe, non-blocking composition, reusable components, stream centric.
Bad: Defers failures to downstream, explicit lifecycle management, glitches, debugging.
Ugly: callback limbo, inverted control flow.
Conclusion: Well balanced within the triangle nodes.
Good: Typesafe, declarative value composition, direct style, deterministic.
Bad: Execution must be single-treaded.
Ugly: Side-effecting can introduce glitches.
Conclusion: Since it is single treaded it is far away from execution node between coordination and compartmentalisation.
Look again on the triangle and then point out all the points (e.g., STM, etc.), and point out the trade offs.
Pick your poison
Enjoyed this talk as well . Very nice and precise summary of concurrency on Scala world.