Tuesday, August 22, 2006

Groovy and Scala Multithread Actors

Parallel exection of Methods.

In my last blog entry I used a MetaClass to change the method execution modell. Some days ago a paper surfaced in the german Java newsgroup about parallel execution of methods in Scala. I found it quite interesting, but maybe there is a way to have that for Groovy too?

I think it is possible using a custom MetaClass again. Again we would collect the method calls, but this time we would use multiple threads to execute the methods. Using a pool for that could be a good choice. Anyway, I don't want to go too much into the details this time, but if you look at my last blog entry and exchange the method execution part with something like:

   stack << method 
while (stack) {
def call = stack.pop()
And then make asynchronous access to the stack to put the frames on, then it would work there too. A special method might be needed to synchronize the method calls again. Something like "metaClass.waitForMethodCalls()". Again we could use a method to switch between parallel and normal execution, just like we have done with recursive and iterative execution before. And of course we have the same disadvantages as the last time. Maybe I will have somewhen a bright idea how to solve the return value problem in a much nicer way than using a global variable. I will let you know it then.

And of course I wouldn't propose such a solution for working on a Cell processor, where we simply use as many Threads for the method calls as cells are available... but maybe, with a bit more research, this could be used to make an efficient execution system without the need to explicitly handle Threads. Yes... well... there is the synchronization problem. Not only to wait for methods to end their calls, but also to synchronize access on variables.

As always when walking on the edge, you should know what you do.


Anonymous said...

Luckily you can use features from java.util.concurrent to do just this (or jsr166 preview jar for lesser JVMs)...

you could wrap the method invocation in a RunnableFuture
and use the ThreadPoolExecutor as your suggested controlling mechanism.

[Doug Lea to the rescue :-) ]



Jochen "blackdrag" Theodorou said...

hi jez...

yes sure... there are possibilities to do that. It is not impossible. And waht I discribed is more like a draft than a implementation. I don't know about you, but I get always more ideas when implementing the stuff. Thinking it all through from the beginning to the end and coming to a superb solution si rar ;) Somewhen you are loosing the ground. Or you analyze the problem from the mathematic point, then it is ok... I was too lazy to do that here.. I hope you forgive me ;)