Monday, September 25, 2006


Limitations of SCOOP

Bertrand Meyer has posted a new article on the EiffelWorld Column called The Challenge of Concurrency. I currently work on a project that is highly distributed. The project has about 15 processes, each with about 8 threads. We are constantly running into bugs caused by some concurrency issue we failed to foresee.

The normal developer action taken to handle concurrency is to wrap every function with a mutex. There is of course no substitute for careful design when it comes to concurrency, so the everything-gets-a-mutex solution inevitably results in hard-to-fix deadlock.

One time a developer was locking a mutex in a signal handler (yeah, we told her it was a bad idea). It would intermittently result in deadlock. Since the signal handler was running in kernel space (I think) it would bring the processor to a halt! We had a very difficult time debugging that, an effort that took an entire week. So, my team and I are very interested in an elegant solution to this complex problem.

I've struggled through the examples at the ETH SCOOP web site. I kind of understand them (although I wish there were examples without the GUI). What I have been unable to find anywhere is an explanation of the limitations of SCOOP. I don't mean limitations due to lack of implementation or support. I mean theoretical limitations. I've read that SCOOP can not support the active object model; I understand this. What I don't understand is what this means for me. Does this rule out SCOOP for my project? Can all concurrent problems be solved using SCOOP?

One thing I've learned with Eiffel is that it sometimes takes a brain retraining. I've seen many people, including myself, stating that something is impossible in Eiffel, only to find that their paradigm was the limiting factor. I'm afraid I might have a limited paradigm (packed with semaphores and mutexes) when it comes to solving concurrent problems. Fully using SCOOP might require a dramatic shift in the way multiple processors are utilized to solve problems, but I don't know. Do any of you?

SCOOP is really a research effort: nobody has developed large applications with SCOOP to tell if the approach is feasible or practical. So, SCOOP is currently were is belongs: in academia.

That said, the computational model of SCOOP is not brand new. Instead, it is very similar to the PVM (itself an extension to MPI) approach in parallel computing, except that SCOOP abstracts from PVM by integrating reasoning about separate references into the type system and partitioning the objects onto the virtual machines.

Looking at the success of PVM, there is a high chance that SCOOP with not be so difficult to grasp, once all the "dark corners" are lit and cleaned up.
There is no SCOOP implementation, so why bother with it?

I heard that Erlang was designed as a concurrent language.
> There is no SCOOP implementation, so why bother with it?

Because I am mostly interested in the potential. Practically speaking, anything other than C++ with a generous sprinkling of mutexes is viewed as heresy. "You want me to let go of my precious mutex? Burn him!!!!!" is what they'll say. It will take many years to change this.

I am excited about SCOOP, but I'll contain my excitement until a compiler-based, full implementation exists and at least a few projects are using it.
You might be interested in my CORDIE06's

The main theoretical limitation of SCOOP
is the fact that it is restricted to the
inter-processor message passing
communication model (which should not be
confused with the message passing
inter-object communication model which
is the essence of object programming).

This is a dual approach to the thread
programming model (which is based, by
definition, in the shared memory [object]
inter-processor communication model).

One immediate consequence of SCOOP's
inter-processor communication model
is the impossibility for an object
to be used concurrently by more than
one processor (intra-object concurrency).
While conceptually appealing, SCOOP has turned out to be very problematic in its details. I think this is one reason it's taken over a decade to get from the initial exposition of the concept to limited demonstrations of it.

Some of the problems have revolved around other concepts in the language, such as the exception handling model, Comment Query Separation, and the "once" keyword.
I think 'Greg C' might have been referring to Command/Query separation!

You may be intersted in Eiflex. Like miguel, I demonstrated this (using the dining philosphers problem as an example) at the cordie06 conference in York.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?