Preventing data races with Pony

The Pony programming language is dedicated to exploring how to make high-performance actor-based systems. Started in 2014, the language's most notable feature is probably reference capabilities, a system of pointer annotations that gives the developer fine manual control over how data is shared between actors, while simultaneously ensuring that Pony programs don't have data races. The language is not likely to overtake other more popular programming languages, but its ideas could be useful for other languages or frameworks struggling with concurrent data access.

Pony was primarily designed by Sylvan Clebsch, who had attempted to write an actor framework in C and C++ while employed at a financial firm. According to Clebsch's description of the motivation for Pony, that system was fast and useful to the company, but it was also plagued by constant bugs:

Over and over again, programmers ran into memory errors. And not just the usual problems with dangling pointers (premature free) and leaks (postmature free?) but persistent problems with data-races.

That experience got him interested in how to do better, and he began a several-year quest to read relevant academic papers and try to synthesize them into a cohesive whole. Clebsch ended up starting a Ph.D. at Imperial College London, where he met other people interested in working on the same problem. They built the system that would become Pony, and released the code under the BSD 2-clause license in 2015, which attracted many more contributors.

Actors

In Pony, a program consists of a set of actors: independent units of execution that own their memory and communicate by exchanging asynchronous messages. Encouraging programmers to break their programs up into multiple actors makes Pony programs well-suited to running on multithreaded systems; the Pony runtime uses one OS-level thread per available CPU, and schedules actors across these threads automatically. It also means that Pony programs don't have global state — all data is owned by one actor in particular, which is important to Pony's data-race-safety guarantees. Declaring an actor in Pony looks like this:

    actor Aardvark
      let name: String
      var _hunger_level: U64 = 0

      new create(name': String) =>
        name = name'

      fun get_hunger_level(): U64 =>
        _hunger_level

      be eat(amount: U64) =>
        _hunger_level = _hunger_level - amount.min(_hunger_level)

Actors are somewhat similar to the objects of object-oriented programming. Indeed, Pony also has classes (although it doesn't support inheritance). The above example of an actor declaration, adapted from the Pony tutorial, looks similar to a class. The difference is that only an actor can call its own methods (indicated with the fun keyword). All that the code outside the actor can do is invoke "behaviors" (indicated with the be keyword), which run asynchronously and don't return results. Invoking a behavior sends a message to the actor, which will pick it up and execute the behavior whenever it is next scheduled. Calling a method is synchronous and runs in the same thread, but invoking a behavior is asynchronous, and may run in a different thread. Unlike private methods in other languages, one Aardvark instance can't even call methods on another Aardvark, only invoke a behavior.

This means that code from the same actor can never be run from multiple threads at the same time (although actors can be migrated between threads by the scheduler). So, unlike object-oriented languages like Java, there is never any need for synchronization within an actor. Each actor has a queue of behaviors that have been invoked, which it processes one at a time, sequentially. If one actor can't keep up with the stream of messages, the programmer can instantiate multiple actors of the same type, and distribute messages between them.

That naturally raises the question of synchronization between actors. Other actor-based systems tend to follow one of two approaches: requiring data to be copied between actors, so that there is no shared data at all, or relying on the programmer to use appropriate locking. Erlang, perhaps the most famous actor-based language, does the former. Unfortunately, copying data between actors has a serious performance penalty, especially for read-only data that wouldn't be subject to a data race in any case. Many actor frameworks for other languages do the latter, which loses a lot of the benefits of an actor-based model compared to just using threads. Pony does neither.

Reference capabilities

Pony's approach is to introduce six different kinds of pointers. That may initially sound like overkill, but the system lets a Pony program model precisely when and how data can be accessed from multiple actors. For example, immutable data that is passed between actors never needs to be copied; the Pony runtime can just pass a pointer, and then access that memory from another thread without synchronization. The six kinds of reference capabilities are:

• Isolated: A unique pointer, for which there are no other references. Because there are no other references, it's safe to send to another actor, giving up access in the process, even though isolated values are mutable.
• Value: Immutable data, that cannot be changed by any actor, and is therefore safe to share.
• Reference: A normal, non-unique pointer that supports reading and writing. Since the pointer is not unique, references cannot be sent to another actor, as that might create a data race.
• Box: A read-only reference. Some other reference might modify the data, but this one cannot. Boxes are mainly used to abstract over whether code is working with a value or a reference.
• Transition: A unique writable pointer to an object that may also be pointed to by some read-only pointers (boxes). Unlike reference pointers, a transition pointer can later be turned into a value pointer in order to freeze the object, since it is unique.
• Tag: A pointer that does not support reading or writing, but it can be stored in data structures and compared for equality with other pointers. Tags are also used for referencing other actors, and the type system allows sending messages using a tag, even though that does require special handling from the runtime.

Isolated, value, and tag pointers can all be sent between actors, because they can't be used to construct data races. References, boxes, and transitions can all be used within an actor, but not sent between them, because they could allow one actor to write to a piece of data that another actor could read. Multiple writable pointers within an actor can't cause a data race, because the code inside an actor executes synchronously.

When an object is initially instantiated, the constructor gives the calling code back an isolated pointer that can be used to modify the object, call methods, etc. The pointer can be passed to another actor (which requires the currently executing actor to give up access to the pointer), or converted into one of the other kinds of reference capability. Most of the kinds can be converted into each other under the right circumstances — for example, any other type can be converted into a tag. Common conversions are to a value pointer to make the object immutable, or to a reference to use internally without sharing. Boxes and transitions are less commonly used, and mostly show up in generic library code. References to other actors are tags, and can be used to invoke behaviors.

These six reference capabilities are structured to be as flexible as possible while still upholding one key requirement: no actor can write to anything that a different actor can read. Then, the runtime system just has to ensure that sending a message between actors is enough of a synchronization barrier to ensure that reads from an actor will see all of the previous writes to the data. With these properties in place, it's impossible to construct a data race in Pony. In fact, the standard library doesn't even include locks, since they wouldn't be of any use to a Pony program.

The whole system is somewhat like Rust's lifetime tracking, in that it is a compile-time analysis that prevents multiple threads from having mutable pointers to the same data. Unlike Rust programmers, however, Pony programmers only have to worry about six specific types of pointer, instead of arbitrary lifetimes. The system can also be used in ways that Rust's lifetime-annotated references cannot. For example, it's easy to build doubly linked lists in Pony using transition and box pointers.

Dealing with garbage

No one solution is ever perfect, however. Pony's message passing is safe, performant, and reasonably simple to reason about. The price it pays is garbage collection. Since Pony doesn't track lifetimes or leave things up to the programmer, it relies on run-time garbage collection. Unlike other garbage-collected languages, however, this doesn't cause noticeable latency spikes.

Other languages have experimented with advanced concurrent, pause-less garbage collectors. But all of them have some pathological cases where garbage can be created faster than it is collected. Pony takes the comparatively simple approach of using a plain mark-and-sweep collector. The trick is that each actor is responsible for its own garbage collection, so the whole program never has to pause at once. Actors also never do garbage collection while they are executing a behavior, and instead perform collections in between processing messages.

Since mutable data can't be shared between actors, even though multiple actors can be referencing a piece of data, the only reference cycles are within an actor's own private data. So actors can treat any external references to their data as being in-use for the purposes of garbage collection, without causing any unreclaimable cycles. This keeps the marking phase of the collector simple, and avoids needing to introduce any synchronization barriers into the garbage collector. Overall, this system results in a remarkably flat latency profile.

Trying it out

The Pony web site includes documentation and tutorials on the language, as well as a playground that runs Pony in the browser, for those who want to try it out without installing. As with Godbolt's Compiler Explorer, the Pony playground will even show the assembly code produced by the Pony compiler.

The project suggests that anyone wishing to install Pony on Linux use the ponyup script (the installation instructions for which sadly involve piping a downloaded script directly to bash), which lets the user easily install and test multiple versions. I ran into some problems using the script on Fedora 41, but it turned out that the Pony release for Fedora 39 worked just fine on Fedora 41. The Pony compiler does require the gold linker from the GNU binutils project, as well as a C compiler supporting at least C11, so those may need to be installed separately.

Once all of the necessary prerequisites are installed, running ponyc in a directory containing Pony source code produces a single, dynamically-linked, native executable. The choice to have the compiler search out and compile all the .pony files in a directory is a bit unorthodox, but it does have the advantage of simplicity. Pony only distributes pre-built releases for x86_64, but does support building for other architectures. The project also recommends building the Pony runtime library from source for the specific microarchitecture that one's application will run on to achieve the best performance.

Conclusion

Pony is not necessarily the right tool for any particular application. For one thing, actor-based systems are mostly best suited to long-lived applications that need to process many requests in parallel. For another, it is driven by a small team of volunteers, which means that it doesn't have nearly as much support available as some other languages. On the other hand, Pony does welcome outside contributions, including new language features, so it might be more adaptable than more established languages. It also has a fairly limited standard library, and hasn't even officially reached a 1.0 release. (The most recent release is version 0.58.7, released on November 30.)

But despite that, Pony's ideas seem like they could be more widely applicable. Most existing languages rely on manual locking, unnecessary copying, or some combination of the two to prevent data races. Copying Pony's approach of simplified compile-time enforcement of a small set of rules for pointers encoded in the type system seems like it could present a safer, more performant alternative.