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

Groups > comp.programming > #891

Re: parallel programming

Show all headers | View raw

On Thu, 29 Sep 2011 14:46:37 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Thu, 29 Sep 2011 09:13:15 GMT, Richard Harter wrote:
>
>> 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.  
>
>If you have a synchronous message from "auton" T to the "auton" S, then
>under certain conditions, especially if the memory is shared, you could
>process the message at the side of T. More specifically if T and S are
>threads. You hold S, call the code S would use to process the message
>directly on the context of T, and then release S. For asynchronous messages
>this trick won't work.

Eeek!! What a deliciously horrid thing to do.    

>
>>>>>>>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.   
>
>Yes, but all these problems are about ensuring that some states are
>coherent in different "autons". There is nothing more than that.

Needing to have states coherent in different autons sounds like a
design error.  Generally in flow based programming it is the data that
should be coherent.  Perhaps it would be best if you would give an
example and we could compare notes.

 
>
>>>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.  
>
>It is not just implementation problem. It is how primitives/constructs work
>together. For example, it is safe to seize a mutex. But it is not safe to
>seize two (potential deadlock). This means that mutex is not a composable
>(under serialization) primitive.

No mutexes in flow based programming.  The guiding principle in flow
based programming is that coherency resides in the data.  Parallelism
generally is effected in the connection graph.
    
>
>Different parallel computing frameworks offer primitives of different level
>of safety under composition. But none is any close to the safety provided
>by procedural composition or OO composition (which also is far from being
>absolute). 

This is a very broad statement.  Unless you put in a lot of caveats it
really isn't true.  

>From a new parallel programming language I expect first and
>foremost addressing this problem, a software developing problem. About
>messages or whatever implementation one can talk later.

There is much to be said for this viewpoint.  However it presumes that
handling parallelism must be embedded in some chosen language.     

>
>>>> 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. 
>
>Yes, but the programmer knows it. The object exists at a higher level of
>abstraction.

In some sense, yes.  And one can say, so?  The key point is that at
any moment in time X exists in only place, either in some auton or in
some queue.  This is not to be confused with the storage location used
for X.  The entire idea of X moving from place to place is not
comprehensible if one only thinks in terms of multiple references at
once.

Incidentally, in the flow based approach, T sending X to S which in
turn sends it back to T is usually a mistake.  What normally happens
is T0 => S => T1 where  => indicates data flow.  
 
[snip]
>>>> 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?
>
>When you send something you need to specify the recipient or else the
>pipe/channel/mailbox to put the message into. This object is shared between
>all participants which may send anything to it, actors deploy n-to-1
>scheme.

Okay.  It's not clear to me that that "sharing" is a useful way to
think of connectivity but you can look at it that way.  In flow based
programming connectivity ordinarily 1-to-1 and almost never n-to-1.  I
hope you will forgive me, but I'm skeptical about actors being n-to-1.
The term, actors, refers to a number of different related approaches.

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