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

Groups > comp.programming > #878

Re: parallel programming

Show all headers | View raw

On Wed, 28 Sep 2011 20:31:53 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Wed, 28 Sep 2011 17:09:49 GMT, Richard Harter wrote:
>
>> On Tue, 27 Sep 2011 10:48:49 +0200, "Dmitry A. Kazakov"
>> <mailbox@dmitry-kazakov.de> wrote:
>> 
>>>OP wants "entities" 1) to be scheduled,
>> 
>> Almost certainly not - he wants delivery of messages scheduled.
>
>That should not make any difference for asynchronous messages. The output
>end of the queue must be serviced by some auton, as you call it. Since the
>messages are asynchronous it cannot be serviced it at the sender's side.
>(That means context switch is necessary for servicing on a single core.)

I'm sorry, this really doesn't make much sense.  Perhaps you might
start by explaining what you mean by servicing a message.  

>
>>>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".
>
>Yes, that is what I meant when doubted that messages could be more
>efficient than tasks. Most likely, they would not.


>
>>>>>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.  
>
>No, it does not mean that. Locking is just a way to synchronize. You always
>need to synchronize at certain points, in order to continue computations
>(to transit to a semantically different state). All problems exist
>independently on the implementation of synchronization.

Granted you need to synchronize, but locking is not "just a way to
synchronize".  Locking is a technique for solving the problems
pursuant to using shared memory.   
>
>The real problem of parallel programming is to have primitives composable
>under the constraint of being free from race condition, deadlock etc. Low
>level primitives are not composable.

In the flow based approach, the "primitives" are implemented as
autons.  

>
>> A second fundamental principle is that objects will only have one
>> reference at a time.
>
>When T sends X to S and then expects S returning X back, that logically is
>a reference to X within T.

Actually, T doesn't know that it is getting X back from S.  All it
knows is that it gets an X like thing on some input port. 

>This is the point where all problems reappear.

You might clarify what problems you think reappear.  
>
>> 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.
>
>OK, queues of references to the objects of the "first kind". Shared objects
>the "second kind" which are either pipes/queue ends or "autons".

That's interesting that you would think of queue ends and autons as
shared objects.  Who or what is sharing them?

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