Skip to main content
On When Concurrency Matters: Behaviour-Oriented Concurrency
  1. Talks/

On When Concurrency Matters: Behaviour-Oriented Concurrency

·313 words·2 mins

Abstract
#

The actor model is one of the great workhorses of concurrent programming. It gives you data race freedom by construction. It scales horizontally as far as the hardware will let it. It lets you reason locally, one actor at a time, one message at a time. Erlang has been doing it for decades. Akka brought it to the JVM. Pony built a whole language around it.

But the actor model has an Achilles heel. Any operation that needs to atomically span multiple actors becomes a protocol. A dance of messages. State machines arguing with state machines across the wire. Easy to get wrong, painful to extend, and so noisy that the actual business logic gets buried under the choreography.

Behaviour-Oriented Concurrency is a paradigm that keeps what the actor model gets right and rethinks what it gets wrong. Instead of state-bound actors trading messages, you have behaviours: units of concurrent work that atomically acquire whatever resources they need to run. The runtime guarantees the acquisition is atomic, the execution is exclusive, and the ordering is consistent. No protocol. No state machines arguing across the wire. Just when (x, y, z) { ... }.

This talk works through the BOC paper from OOPSLA 2023, by Cheeseman, Parkinson, Clebsch, and friends. We start with what the actor model gets right and why so many people built systems around it. We walk to where it falls down. Then we get to how BOC fixes the gap without giving up what makes the actor model worth using.

Versions of this talk
#

  • Papers We Love San Francisco - Slides

Links#

References
#

Related

GC Made Fast

·229 words·2 mins
Most engineers think GC is slow. They’re wrong. Coordination is slow. Pony’s per-actor heaps and message-passing model eliminate the coordination that makes traditional garbage collectors a performance problem.