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

Groups > comp.programming > #876

Re: parallel programming

Show key headers only | View raw

On Tue, 27 Sep 2011 10:48:49 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Tue, 27 Sep 2011 02:03:29 GMT, Richard Harter wrote:
>
>> 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:
>> 
>>>> 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.
>
>I mean that "task" is a generalized term. For a concrete platform it could
>be process, thread etc.

Okay.  It's still problematic, but that's a separate topic.  In this
discussion I am going to use the term "auton" which is an abbreviation
of "autonomous computing element".
>
>> Secondly, tasks in the ADA sense
>> may be heavy weight for what the OP wants.
>
>Though I didn't have specifically Ada tasks in mind, I don't think that
>they would be more heavy-weight. Ada tasks require 1) scheduling, 2) a
>queue of tasks awaiting for a rendezvous, 3) stack. 

>OP wants "entities" 1) to be scheduled,

Almost certainly not - he wants delivery of messages scheduled. 

> 2) to have messages queues, 3) to have local memory.

ayup. 

>The
>latter looks more heavy-weight, because queues of tasks may have fixed size
>(the number of tasks is limited), fixed size elements (pointers to TCB),
>events on which the queue must be serviced are well-defined etc.

I doubt that the number of entities is fixed.  IIANM queues contain
messages, not "tasks".
>
[snip]
>
>>>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.  
>
>Well, if you have an asynchronous interface you have to marshal at least to
>ensure that the objects being passed are not concurrently updated. Any
>locking schema is in effect a synchronization.

This is quite wrong, although I didn't realize it until I read his
followup.

>
>>>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".
>
>The point is that any design would be exposed. If your point is that some
>good design would preclude the user from falling into one of these highly
>undesired situations, then it would become *much* more than just messages.

Ditto, this is also wrong.  You need to understand the design
paradigm.  In both the flow based programming paradigm (which I am
familiar with) and the actors paradigm (which I have a reading
knowledge of) there is a fundamental principle - there is no user
visible shared memory.  This means that locking and protected
operations are non issues.  

A second fundamental principle is that objects will only have one
reference at a time.  (In flow based programming this may be
qualified.)  In consequence physical race conditions again tend to be
non issues.

Flow based programming and actors based programming use two different
models.  The fundamental component in flow based programming is the
auton (aka component), a persistent computational unit (think very
light weight user processes).  Application consist of a network of
autons connected by pipes.  Objects are sent from one auton to another
via pipes.  This means that it is safe to pass references rather than
copies; ergo marshalling is not a major issue.

In actors based programming the fundamental components are the objects
themselves.  Messages are passed back and forth between objects.  OP's
model is actors based - see the response to your post.  Given the
development context, the term "entities" is quite natural, albeit
confusing in a broader context.  To be honest, I am much less familiar
with the actors paradigm than I am with the flow based paradigm.

  

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