samskivert: Hazard Reduction in Scala Actors – Stiegler

06 October 2009

Stiegler decries the existence of four hazards of using actors in Scala: global mutable state, the ability to pass a mutable object into an actor’s constructor, the ability to pass a mutable object as a message to an actor and the ability to capture mutable state when defining an actor as an anonymous closure. He then proposes a mechanism to mitigate these hazards which comes in the form of Actress, a wrapper around the Actor class, and Sendable, a root type that identifies legal (ostensibly immutable) arguments to be provided to the Actress constructor and which must be sent as messages. He also proposes that the protected Actress.make() method, which is used to define the body of the actual Actor wrapped by an Actress, encourages the programmer to avoid constructs that might capture mutable state.

The fundamental problem that the proposal attempts to address is no doubt valid: Scala has mutable state, this introduces dangers when writing concurrent programs. Unfortunately, the proposed technique is neither elegant, nor an especial improvement on the current state of affairs.

In a language which allows mutability we have two approaches when it comes to providing mechanisms for concurrent programming (I’m going to ignore the third approach of “do nothing to discourage the programmer from hurting themselves,” one that has proved all too popular in the past):

1. Provide a type system that can represent propositions about mutability and immutability and design your concurrency mechanisms to make use of that type system to ensure that only immutable data is shared between threads. This is the difficult solution and incidentally one of my research interests. I conjecture, in fact, that immutability is a stronger requirement than is needed and a truly useful system will allow some mutability in provably safe circumstances.

2. Design your concurrency mechanisms such that they provide a clear indication to writers and readers of code that We Are Now Doing Concurrent Things: Be Careful! One benefit of the actor model is that it does exactly that. When you are creating an actor you are reminded that you are in the dangerous realm of concurrent programming, and thus motivated to heed the lessons of the past and use mutable state carefully and sparingly. You know it is a bad idea to send mutable state between actors in a message, so you don’t.

I believe that approach number one is worth pursuing, but it will have to provide a meaningful improvement over approach number two which, though only recently adopted over the “do nothing” approach, seems to be helping quite a bit.

Stiegler’s proposal provides no such improvement. It is a thin veil of annoyance standing between the programmer and doing the wrong thing which is altogether too easy to rip through.

I’ll stop ranting now. Clearly a solution that achieves an increase in safety through a reduction in elegance and convenience rubs me the wrong way. On the plus side, I can thank the author for redoubling my interest in working on a proper solution to this problem.

Source: PDF

©1999–2015 Michael Bayne