Re: RFC - New Object-Oriented Method of Parallel Programming

On Thu, 30 Mar 2006 21:23:42 +0200, Slawomir J. wrote:

http://www.stressflow.com

For those who can spare the time to look at it - I would appreciate all
comments and suggestions.

Greeting!

I don't have spare time, but it is always interesting to see of there is
something new in that area.

Critique / Analysis:
------------------------

1. Stress-flow atom is a specialized version of a task.

2. Tasks aren't full ADTs, which is actually the problem with them. In
particular they don't have user-defined constructors, which could play the
role of the "stressed section". Presently this problem is solved using a
mix-in parameter (discriminant) or else an initialization rendezvous.

3. I don't see any advantages of stress-flow specialization of tasks. Note
that task is far more flexible. It terms of stress-flow a task can have
multiple "stressed sections" in the form of rendezvous.

4. The "dining philosophers" example raises further questions. First it is
very low-level. Forks are implemented as mutexes. Mutexes are known to be
not composable. The deadlock prevention you refer, is based on an awkward
mechanism of taking all mutexes at once. But it is the programmer's
responsibility, so deadlock will be still possible, if later on another
mutex will be taken.

5. From OO perspective mutexes should clearly be replaced by protected
objects, which are more efficient as well.

6. If that were done, then ordering of mutexes, which is a more general
solution of the "dining philosophers" problem, could be replaced by a
protected action on a multiple objects, looking as a double dispatching
take:

Take (LeftFork, RightFork);

This is close to your example, but as I said above it is still low-level. I
am not sure if an OO solution exists, such that creates a new type out of a
pair of forks.

7. Exceptions. How exceptions propagate out of relaxed sections up to the
caller. What happens with the offspring tasks upon winding up the stack of
the parent? In particular, what happens with mutexes taken?

8. Timed calls. I saw nothing close to that in your proposal.

9. The main critique is that so far it is not OO at all. From OO point of
view stress-flow + mutexes is even more low-level than tasks + protected
objects, which at least, are itself objects and have types. Basically what
you describe is in my view, just aggregating a task (called stress-flow
atom) into some proper OO object. This isn't OO.

---------------------------
As I see it, OO begins when you *inherit* from a concurrency primitive. For
example when you inherit from a task. Or when you inherit from a protected
object. The great problem with inheritance is how to override entry points,
protected actions (="stressed section"), execution paths (="relaxed
section".) In short, what about "virtual detach". So far I saw no good
proposal regarding these problems.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.