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

On Sun, 2 Apr 2006 16:11:19 +0200, Slawomir J. wrote:

"Dmitry A. Kazakov" wrote:
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.

Well, time will show if my (obviously subjective) view is correct, but I
see, what at first may appear as limitation, as means of accomplishing far
more at the end. Let me give you an example. In early days of computer
science programmers would often call/jump into the same procedure at
different points. The very essential part of going away from this "dirty"
machine level programming was code writers disciplining themselves into
going away from this flexibility and writing routines with one entry points.
Without this "limitation" no universal libraries and no OOP would be
possible, as it would make impossible for the compiler to automatically
insert constructor calls.

I definitely agree with the principle of "least power" regarding language
constructs. But I disagree that your proposal embodies that principle.
(:-))

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.
That's incorrect - and it beautifully proves validity of my previous answer.
The simple model of abstraction (stressed/relaxed sections driven by
automatically inserted by the compiler lock) permits using this scheme to
replace all previously used rudimentary synchronization tools and to move
necessary synchronization to be the foremost visible part of procedure
structures. Reserving all required locks or none at all is very easy to
implement, as well, and in this programming model possible by multi-step
process of calling a stress-flow atom, with the lock reservation command
always being first of them.

I don't see how this might prevent deadlocks. Even if we consider only
lockers associated with the stress sections, I can still refer to other
atoms within a stress section, i.e. with a lock taken.

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?

Exceptions are actually almost completely unnecessary in the model proposed.
The exceptions allowed getting out of string nested calls to a place outside
of it. Every stress-atom call is sort of an exception already - allowing
splitting and re-merging multiple paths and not following the linear
hierarchy of control-flow code.

No. Exceptions are synchronous in the sense that any execution path has
either an exception propagating or no one.

[ Asynchronous exceptions might useful in some specific cases, but it is
another story.]

A lack of consistent exceptions support is a great deficiency. I understand
that it is almost impossible in a data-flow model. (:-)) But that does not
wonder me. Having some experience with data-flow oriented languages like
Simulink, LabView, DiaDem and some others, I'm almost certain, that their
proved useless for anything decent, large scale, safe, shows nothing but
general weakness of the data-flow programming paradigm, when it comes to
human programmers, of course. It is unsuitable for humans.

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

A timer object (ideally a device driver wrapper for some timer hardware)
performs calls to stress-flow atoms that needed directly or through the
"connector" construct. Exactly the same generic scheme.

No I meant a different thing. Timed call is a blocking call to some
synchronization primitive, which can be prematurely aborted because of
violating a time constraint. [ Aborted here means in a safe way, keeping
all objects' invariants intact. ]

I looked at OO at its more generic sense, defined as:

******************

The idea behind object-oriented programming is that a computer program may
be seen as comprising a collection of individual units, or objects, that act
on each other, as opposed to a traditional view in which a program may be
seen as a collection of functions or procedures, or simply as a list of
instructions to the computer."

******************

The above is about modularity. It tells nothing about how modularity is
achieved.

From that point of view, allowing objects to act autonomously on their own,
independently from other objects whenever possible, should have been far
more important in OO defined above than inheritance.

First, modularity isn't whole OO. It just does not imply OO. Then even if
it did, nothing in your proposal shows a better modularity or decoupling.
Data flow is a very tight coupling. In OO terms it is coupled on the basis
of concrete instances (objects.) It is extremely low-level. OO design is
based on weaker couplings between types and classes of types. These
couplings hold for all instances.

To use an analogy -
suppose we have some sore of life game/life-like simulation. Being able to
program the creatures so they can live their own lives on their own,
independently whenever possible, is far more important than being able to
design them in such a way where you can easily replace their arms with
hooks - which is what inheritace is basicly about. ;)

It is a too narrow view. Writing a simulation you need a class of
creatures, you need to reuse common things among creatures, you need
creatures communicating each other and the environment.

Anyway, IMO a consistent proposal should deal with inheritance and more
generally with types and classes. OO is largely about generic programming,
i.e. designing code dealing with sets of types. Inheritance is just a tool
to fill classes. Hypothetically, you are free to propose a better tool, but
you cannot dismiss classes without throwing OO away with it. Basically you
have to answer: how to solve a class of problems requiring concurrency with
maximal possible code reuse. As long as concurrency atoms don't induce
classes, it isn't OO.

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

Relevant Pages

  • Re: RFC - New Object-Oriented Method of Parallel Programming
    ... It terms of stress-flow a task can have ... machine level programming was code writers disciplining themselves into ... Exceptions are actually almost completely unnecessary in the model proposed. ... The great problem with inheritance is how to override entry ...
    (comp.object)
  • Re: Cpp Considered Harmful
    ... programming language, the compiler, the IDE, the libraries, etc. ... WRT exceptions, the fact of the matter is that placing certain ... >> regarding the CPP. ...
    (comp.lang.cpp)
  • Re: I cant believe how complex this Format SDK is...
    ... Programming in general is never considered a breeze, ... provides me with an unbiased perspective on the docs and APIs. ... Overall I think the documentation is reasonably good, ... run my app in the debugger, such as first-chance exceptions when using ...
    (microsoft.public.windowsmedia.sdk)
  • Re: 8 years of C++ Exception Handling
    ... >> Are the points you wrote above recommendations or attempt at ESP? ... state them as positive or negative attribues to good programming. ... C++ exceptions are still one of the areas where there is lack of clear ... </below the belt> ...
    (comp.lang.cpp)
  • Re: EE Student, Edit, Proposal Masters, Help (concepts of functional programming, symbolic programmi
    ... Common Lisp is no longer a pure ... > functional language some functional programming language lisp dialects ... implementor of haskell to implement exceptions? ... > necessary in Maple because Maple is not a pure functional language. ...
    (sci.math.symbolic)