Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #864

Re: parallel programming

Show all headers | View raw

On Fri, 23 Sep 2011 16:56:43 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Thu, 22 Sep 2011 11:30:45 -0700 (PDT), vincent_belliard wrote:

I looked over the web site.  To be honest, the conception and the
development are far too immature to evaluate.  However I am left with
the impression that the author hasn't done his homework.  Here are
some issues:

(1) Entity is a terrible name.  Better names for the "entities" would
be names such as tasks, light processes, light threads, components, or
other terms used in the literature.

(2) Message passing is much too vague.  There are many ways to define
a message passing system with very different properties.

(3) The documentation covers the relatively unimportant stuff
(describing yet another object oriented language), and omits all the
important stuff, e.g., the implementation model, and the message
passing protocols.

(4) It doesn't appear that OP is familiar with the literature on other
languages that promise easy parallelism.  One reason for scanning the
literature is that one can get a sense of what one likes and dislikes.

Overall the documention and description read as though someone had a
bright idea and plunged into an implementation.  Not a bad idea,
really.  It's a good learning experience. 

That said, I have a few comments on Dmitry's remarks.  They will be
from the flow based programming perspective just as his are from an
ADA perspective.
  
>
>> Making parallel programs has always been tedious. In Entity (http://
>> code.google.com/p/entity-language), it can nearly be transparent. The
>> concept of entities is made for that. An entity is a small unit of
>> processing.
>
>What is wrong with the established term "task"? A task is a subject of 
>scheduling that owns at least stack and, optionally, a heap.

There are a whole suite of terms that one might use, e.g., process,
thread, mini-thread, green thead, user process, etc.  They all tend to
be partial fits.  Task is problematic, but it might fit what OP is
doing.  I have some reservations about your definition.  Firstly, heap
and stack are too OS model specific.  Secondly, tasks in the ADA sense
may be heavy weight for what the OP wants.  Thirdly the established
term means different things to different people.  Here are a couple of
definitions to illustrate the point.

http://whatis.techtarget.com/definition/0,,sid9_gci213094,00.html

    In computer programming, a task is a basic unit of programming 
    that an operating system controls.  Depending on how the 
    operating system defines a task in its design, this unit of 
    programming may be an entire program or each successive 
    invocation of a program.  Since one program may make requests of 
    other utility programs, the utility programs may also be 
    considered tasks (or subtasks).  

http://en.wikipedia.org/wiki/Task_%28computing%29

    A task is an execution path through address space.  In other 
    words, a set of program instructions that are loaded in memory.  
    The address registers have been loaded with the initial address 
    of the program.  At the next clock cycle, the CPU will start 
    execution, in accord with the program.  The sense is that some 
    part of 'a plan is being accomplished'.  As long as the program 
    remains in this part of the address space, the task can continue, 
    in principle, indefinitely, unless the program instructions 
    contain a halt, exit, or return.  
    
    In the computer field, "task" has the sense of a real-time 
    application, as distinguished from process, which takes up space 
    (memory), and execution time.  
 
>
>> It has a separate memory. Communication between entities
>> is made sending messages. This is the only way to communicate. You
>> send a message to an entity without expecting any result. If the
>> callee entity wants to send a result, it sends a new message to the
>> first entity. This mechanism is built inside the compiler so, sending
>> a message is like calling a function.
>
>This is a very low-level model.

Piffle.  Unless you have extracted more out of the documentation than
I have neither you nor I anybody else (including the OP, I fancy)
knows what sort of message passing OP will end up with.  Repeat after
me, message passing is a generic term.  Without further information
the message passing may be sychronous or asynchronous, and typed or
untyped. 

>More advanced concurrent languages support 
>task synchronization mechanisms rather than asynchronous channels of 
>untyped messages. The issues are:
>
>1. Lack of synchronization, rendezvous, RPC, protected operations are 
>synchronous;

Rendevous and RPC can be managed with asynchronous channels.  It all
depends on protocols.
>
>2. Untyped approach. The above mentioned mechanisms are strongly typed.

See above.
>
>3. Inefficiency compared to protected operations and rendezvous (mechanisms 
>that do not require marshaling). Protected operations additionally may 
>require to context switching.

I gather that your argument here is that sending full copies rather
than references is expensive.  Granted.  That marshaling is
obligatory, not granted.  

>
>4. Messages are exposed to race conditions, deadlocks, live-locks. 
>Protected operations under certain restrictions support static 
>schedulability analysis.

I grant that badly designed message passing system are subject to race
conditions, etc.   Note "badly designed".

Comment 1:  My take is that applications should be written so as to
work with asynchronous message passing but that the implementation can
use synchronous message passing for efficiency reasons.

Comment 2:  There is much to be said for separating the specification
of connectivity (which can be done declaratively and is language
independent) and the implementation language(s) used in components,
tasks, whatever.

[snip remainder]

Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

parallel programming vincent_belliard <vincent@famillebelliard.fr> - 2011-09-22 11:30 -0700
  Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-09-23 16:56 +0200
    Re: parallel programming cri@tiac.net (Richard Harter) - 2011-09-27 02:03 +0000
      Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-09-27 10:48 +0200
        Re: parallel programming vincent_belliard <vincent@famillebelliard.fr> - 2011-09-27 02:40 -0700
        Re: parallel programming cri@tiac.net (Richard Harter) - 2011-09-28 17:09 +0000
          Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-09-28 20:31 +0200
            Re: parallel programming cri@tiac.net (Richard Harter) - 2011-09-29 09:13 +0000
              Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-09-29 14:46 +0200
                Re: parallel programming vincent_belliard <vincent@famillebelliard.fr> - 2011-09-29 10:19 -0700
                Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-09-30 10:33 +0200
                Re: parallel programming cri@tiac.net (Richard Harter) - 2011-10-01 16:12 +0000
                Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-10-01 20:27 +0200
                Re: parallel programming cri@tiac.net (Richard Harter) - 2011-10-02 19:29 +0000
                Re: parallel programming "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2011-10-03 09:13 +0200
                Re: parallel programming cri@tiac.net (Richard Harter) - 2011-10-03 05:49 +0000
  Re: parallel programming Rui Maciel <rui.maciel@gmail.com> - 2011-09-29 12:03 +0100
    Re: parallel programming vincent_belliard <vincent@famillebelliard.fr> - 2011-09-29 10:28 -0700
      Re: parallel programming Rui Maciel <rui.maciel@gmail.com> - 2011-09-29 23:09 +0100

csiph-web