Skip to content
 

Concurrent Scheme

While I wait for my 1-hour mobile phone software compilation to finish I decided to drop a quick post about something that has been on my mind lately. In his nice PhD thesis (that I had to read five times to finally understand it), Dybvig (the implementor of Chez Scheme) shows a compiler that rewards the pure functional use of the Scheme language. The compiler scans for free variables in lambda forms and, when creating the respective closures, put the values of the variables directly in the closure activation frame. The references to the free variables in the closure are then changed to references to the stack locations. Accessing the variables is then pretty fast. Besides, when a first-class continuation is created, it suffices to blindingly copy the execution stack because all closures will carry their free variables with them. Assignment is then added at a later section of the thesis. To support it the compiler scans the code for set! forms, gathering the variables that are ever assigned, and compiling them to indirections to heap memory. When a continuation is created the indirection box is copied, not the actual variable, which lives in the heap. So access to assigned variables is much slower.

Although the focus of Dybvig’s thesis is not on concurrency, I cannot help but think that his compiler could work very well for this too with just minor modifications. If variables (local or free) are never assigned, they could be replaced by their values and several different threads with different execution stacks could run in parallel. If a variable is assigned, the access to its indirection box could be protected by a mutex or similar synchronisation primitive. Of course this would make access to assigned variables even slower, because even variables ever used by only one single thread would need mutex lock/unlock operations. On the other hand, isn’t assignment discouraged in Scheme? The overall execution time would compensate for this, if the rest of the program was parallelised.

But surely I am missing something, because no one ever seems to think Scheme can be a contender in the massive-parallelised future. What bugs me is that I don’t know what it is that I am not taking in consideration.

6 Comments

  1. Hélio says:

    Well… why not ask him? :)

  2. James Iry says:

    Mutexes on shared mutable memory are a particularly difficult way to deal with concurrency. If you’re interested in Lisps and concurrency check out Clojure. The author, Rich Hickey gives a nice presentation on a ridiculously parallel ant colony simulation here: http://clojure.blip.tv/file/812787

  3. The current version of Chez Scheme features true concurrent, parallel threads.
    If you are interested in implementation details, see Dybvig’s home page.
    Look for his retrospective paper on the development of Chez Scheme.
    See also his paper on the parallel garbage collector.

  4. George Kangas says:

    Another concurrency approach in Scheme is called “termite”, which is a library supported by Gambit Scheme. It’s basically shared-nothing-message-passing, as in Erlang.

    I haven’t actually played with it; I’m just a dilettante who reads blog posts.

  5. [...] « Concurrent Scheme Toy Scheme interpreter in Lua » [...]

Leave a Reply