Actors package

I just completed version 1.0 of a new Actors package. This implements a system of Green threads across a dynamically expandable pool of OS Executive threads. Executive pools are created on first demand whenever an Actor exchange is initiated. Written entirely in LW Lisp, no external C libraries needed.

Initial benchmarks showed that a simple message send + thread teardown across 10 million Actors took about 82 seconds on my Mac Mini with 4 CPU cores. That’s 8 usec per context switch. The Mac remained responsive during that test, and the pool never needed to augment the original 4 Executives in the pool. The CPU meter showed a steady 270% utilization across all 4 cores.

The performance scales linearly from 1,000 Actors to 10 Million Actors. Below 1,000 Actors the test is too fast to get timings, and I didn’t bother attempting more than 10 Million Actors.

The Executive pool implements a system for managing the OS threads that allows for blocking activity in Actor green threads, whether the result of blocking I/O calls, or just compute bound Actors. A system watchdog keeps an eye on things to automatically spawn off additional Executive red pool threads if it detects that all of the pool Executives have been tied up for too long while Actors await in the ready queue. 

So this also solves the problem of deadlocks arising from Actor messaging loops. Most of the time, with normal activity, even with blocking I/O, things run happily given the other available Executives living in the pool. I put a limit of 1,000 Executives when growing before barking at the user. The system is very fluid and does not seem to bind up and become unresponsive.

SMP coordination is only needed in the Executive pool, the ready queue, global shared data (when you really must), and each Actor object when you need to read / write consistent data in the object itself. Actors otherwise maintain their own persistent state in closure bindings so that the code in their body can assume single thread unencumbered access to local state. Reentrant code is never needed in Actor bodies because they can only be instantiated for running on one OS thread. That’s a huge burden lifted from most complex code. So much so that portions of the Actor system were migrated to Actors when possible.

[ I’m too much of a lamer to deal successfully with GitHub after just trying to upload for the past half hour. I give up. ]

The Actor system benefits greatly from Doug Hoyte’s DLAMBDA and the Optima MATCH, although neither is mandated by the Actor system. These two just make life much nicer for you.

My earlier Butterfly system was entirely OS thread based and is quite versatile for distributed computing here in the lab and elsewhere. But it was always heavy compared to Erlang. Now we have the potential for the best of Lisp, combined with lightweight and simple to use concurrent programming.

- DM

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
lisp-hug@lispworks.com
http://www.lispworks.com/support/lisp-hug.html