Posted tagged ‘Parallelism’

On massively parallel coderacks

March 11, 2008

Here’s a question: how to make FARG massively parallel? I’ve written about parallel temperature, and here I’d like to ask readers to consider parallel coderacks.

Like temperature, the coderack is another global, central, structure. While it only models what would happen in a massively parallel minds, it does constrain us from a more natural, really parallel, model. Though I’m not coding this right now, I think my sketched solution might even help the stale codelet problem Abhijit mentions:

We need the ability to remove stale codelets. When a Codelet is added to the Coderack, it may refer to some structure in the workspace. While the codelet is awaiting its turn to run, this workspace structure may be destroyed. At the very least, we need code to recognize stale codelets to prevent them from running.

Consider that most codelets fit into one of three kinds: (i) they can propose something to be created/destroyed, (ii) they can evaluate the quality of such change, and (iii) they can actually carry it out.

Now, whenever a codelet is about to change something up, why add it to the global, central, unique, coderack? I don’t see a good reason here, besides the “that’s what we’ve always done” one. If a codelet is about to change some structures in STM, why not have (i) a list (or a set, or a collection, etc.) of structures under question & (ii) create a list-subordinated coderack on the fly? Instead of throwing codelets into a central repository, they go directly to the places in which they were deemed necessary. There are multiple repositories for codelets.

Why do I like this idea? First, because it enables parallelism of the true variety. Each of these STM-structure-lists-bound coderacks can be running in their own thread. If some crazy codelet wants to change some set of structures, it needs to find the proper coderack, or to create it during a run. This means codelets cannot interfere with STM structures to which they haven’t been assigned access; & the STM-structure-list-coderack will assure that only one codelet goes at a time.

Moreover, it helps us to solve the stale codelets issue, by simply destroying the coderack when something needed inside the lists is gone. If a structure is destroyed, and a codelet was waiting to work on it, the codelet–in fact all the coderacks associated with the structure–can go back to cyberspace heaven.

How about programming this thing? It doesn’t even have to be too hard. It can be done gradually, as all the coderacks can be running in simulated parallel and fully tested before venturing into the dangerous waters in which the threads lead us.

(I don’t know when I’ll be able to try this idea out, but hopefully, one day soon.)

Does that make any sense?