Tag Archives: concurrency

Gruple: A Tuplespace for Groovy

I’d like to announce the first release of Gruple, a tuplespace implementation for Groovy (and Java, of course.) Release 1.0 is an *in-process* space only, meaning that it can be used to co-ordinate and synchronize threads, but not separate processes. It’s intent was to add one more tool to the toolkit for making concurrent programming simpler. (A remote space, allowing co-ordination among separate processes and/or nodes is on the roadmap, but not near the top.)

You can find the project at http://gruple.googlecode.com

After downloading and building the source (there’s an ant buildfile to make it easy enough), please read the Demos page for some instant gratification. 😉

Please enjoy it, and I appreciate any feedback (including bug reports!)

Happy concurrent programming!

Loosely-Coupled Actors: In Brief

Actors are a popular way to write concurrent & distributed programs. Immutable messages are passed between actors which do the required processing, avoiding the difficulties inherent in sharing data among threads/processes.

Tuplespaces (best exemplified in current times by JavaSpaces) are a way to decouple cooperating processes by using pattern-matching to share immutable and persistent data objects.

Many distributed algorithms can be modelled as a flow of objects between participants.

JavaSpaces(TM) Principles, Patterns, and Practice

Or, if you prefer, substitute “parallel” for “distributed” and “messages” for “objects”.

So what do you get if you combine the pattern-based communication of tuplespaces with the message processing paradigm of actors? Loosely-coupled actors.

Actually, as I see it, you get two things:

  • An easier way to write tuplespace programs: the actor DSL provides a formalism for describing reading, writing, and consuming of tuples and the behaviour associated with these operations.
  • Pattern-based communication between actors with no explicit reference to each other: actors are decoupled in both (address)space and time (since messages are persistent objects.)

In both cases, a (hopefully) better way to write concurrent programs.

To the best of my knowledge, no one has tried this yet.

Note: I wrote a longer piece on this topic yesterday with more explanation and references. For those wanting a little more…

Loosely-Coupled Actors

Recently the growing concern with effective use of multicore processors and the subsequent popularity of the actor model came together with my desire to do a project in Groovy. Adding to the mix, I had an in-JVM tuplespace library in Java I’d never released because it seemed thread co-ordination was just not enough of a big deal. Now, with the need to simplify and promote good multi-threaded programming practices, I thought it might be worth translating it into Groovy as a learning exercise (I’m new to Groovy) and releasing it as open source.

But the actor model and tuplespaces kept getting mixed up in my head. Like chocolate and peanut butter, I just wanted them both at the same time. What I really wanted was loosely-coupled actors.

Actors

The actor model uses the passing of immutable messages to avoid the problem of shared state in concurrent and parallel programs. This is a gross oversimplification, but a deeper discussion is beyond the scope of this post. If you want a better explanation, this two-part article (part 1, part2) by Alex Miller really helped me out. (Don’t let the Erlang stuff in Part 1 turn you off, he gets to Scala, Java, and Groovy eventually.)

Tuplespaces

In a tuplespace–again grossly simplified–there are no shared variables, but there is a shared data space filled with immutable objects. These objects are accessed not by address, but by their contents. A tuplespace is an associative shared data store. These objects, or tuples, can be thought of as messages. They are matched by templates inserted into the space by other components or processes, rather than delivered to a named end-point. A tuplespace is a realization of the “generative communication model” because messages are first-class, shared objects. But in this model communication is uncoupled rather than point-to-point.

Digression: Assembly by Diffusion

A passage in Manuel Delanda’s Intensive Science & Virtual Philosophy, does something to explain why I am so attracted to spaces as a communication mechanism. It’s not an exact analogy, by any means, but it gives a flavour of the “open combinatorial spaces” that the generative communication model creates. Here’s an excerpt:

[Biological assembly] permits the transport processes not to be rigidly channelled, using simple diffusion through a fluid medium to bring the different parts together. Components may float around and randomly collide, using a lock-and-key mechanism to find matching patterns without the need for exact positioning.

I think that’s a pretty fair description of “loose coupling”: no rigid channels; no exact positioning; parts brought together by pattern matching. Tuplespaces would seem to act like the aforementioned fluid medium, allowing components to work together in an almost organic manner.

ActorSpaces

Agha and Callsen describe the idea of an ActorSpace. Have I finally found what I’ve been looking for? Well… not quite. Agha and Callsen do recognize the importance of “pattern-based communication between processes which have no explicit reference to each other” for open distributed programming. However, they chose to base their pattern matching on attributes of actors themselves. This introduces a new element to the actor model–attributes–and it is not entirely clear what these attributes might be or how to use them to abstract communication. Interesting paper, but it doesn’t quite scratch my personal itch.

Tuplespaces + Actors

Many distributed algorithms can be modelled as a flow of objects between participants.

JavaSpaces(TM) Principles, Patterns, and Practice

We could as well substitute “parallel” for “distributed” and “messages” for “objects”.

Considering the quote above, the actor DSL provides a way to define the “participants”, describe their behaviour, and manage their lifecycle. The tuplespace operations provide the pattern-directed flow of messages.

The result is:

  • An easier way to write tuplespace programs: the actor DSL provides a formalism for describing reading, writing, and consuming of tuples and the behaviour associated with these operations.
  • Pattern-based communication between actors with no explicit reference to each other: actors are decoupled in both (address)space and time (since messages are persistent objects.)

In both cases, a (hopefully) better way to write parallel programs.

So the bottom line of all this is that my little Groovy tuplespace project is trying to grow into something more: using a tuplespace paradigm to provide pattern-matching based on messages and processing of these messages by actors: loosely-coupled actors.