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?
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?
posted by Brian Heilig @ 21:16 
Comments:
<< Home
There is no SCOOP implementation, so why bother with it?
I heard that Erlang was designed as a concurrent language.
I heard that Erlang was designed as a concurrent language.
# posted by 
: 26 September, 2006 15:02
: 26 September, 2006 15:02
> 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.
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
presentation:
http://www.ieeta.pt/~mos/pubs/cordie06-mos-presentation.pdf
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).
presentation:
http://www.ieeta.pt/~mos/pubs/cordie06-mos-presentation.pdf
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).
# posted by : 26 September, 2006 16:27
: 26 September, 2006 16:27
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.
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.
Brian,
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.
www.eiflex.com/reliable_components_paper.doc
Post a Comment
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.
www.eiflex.com/reliable_components_paper.doc
# posted by : 27 October, 2006 00:10
: 27 October, 2006 00:10 << Home
