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

Groups > comp.programming > #898

Re: parallel programming

Show all headers | View raw

On Sat, 1 Oct 2011 20:27:12 +0200, "Dmitry A. Kazakov"
<mailbox@dmitry-kazakov.de> wrote:

>On Sat, 01 Oct 2011 16:12:55 GMT, Richard Harter wrote:
>
>> 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:
>>>
>>>> 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.
>
>"Data" is merely an interpretation of states. E.g. when the floppy disk has
>its surface in a certain state, we treat this state as the disk containing
>a file with the program hello-world in it.
>
>Anyway coherence of data distributed over a network of "autons" is again
>synchronization at the next, upper abstraction layer (where data first
>appear).

You seem to be missing the point.

[snip]

>>>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.
>
>Otherwise parallel programming would represent no problem (compared with
>non-parallel programming).

This is a non sequitur.

>> However it presumes that
>> handling parallelism must be embedded in some chosen language.     
>
>What else is a programming language for? I presume for programming... If
>programming is parallel, so must be the language.

Er, let me clarify.  Consider a typical flow based application with
three basic components, a run-time system, a flow graph specification,
and a suite of autons.  Each auton API consists of input ports and
output ports, both with a standard port protocol.  The flow graph
specification specifies the connectivity, i.e., which output ports are
connected to which input ports.  The run-time system handles
scheduling the delivery of messages, and determining what autons are
loaded where.

The autons can be written in any language provided that (a) the object
code can be linked into the application, and (b) they can receive and
send messages.  The flow graph specification is (can be) a text file
that is read by the run-time system.

If you like you can think of the flow graph specification as a
declarative programming language.  The question at hand is:  If the
application has parallelism, where is it specified and managed?  In
general, not in the autons.  Each response to an incoming message is a
single thread of control.  Rather it is done by the run-time system in
response to the flow graph specification.

The point I was getting at is that one need not use special languages
to implement parallelized and distributed applications.  This is an
advantage.  The downside is that the application code has to observe
the flow based protocols.

  
>
>>>>>> 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.
>
>No, at this level of abstraction that is just an implementation detail.

Wrong , wrong and wrong!!!  It is an essential invariant. 

>The
>programmer does not care how the language handles the object so long the
>semantics is same. Compare it with how variables are handled by a higher
>level language. The variable can be allocated in the memory, have copies in
>the cache and registers. You don't care if the result is correct, consider
>it "the variable", though there might be no such thing in reality.

The semantics are changed.
>
>> Incidentally, in the flow based approach, T sending X to S which in
>> turn sends it back to T is usually a mistake.
>
>That would mean that the described abstraction (mutable shared object)
>cannot be safely implemented in this approach. Example: let you have an
>image. That is the object you wanted to process (say, sharpen). You cannot
>send its pieces to the concurrent workers and get the result back?

Actually you can if you have a splitter/repackager pair of autons.
The splitter generates m new objects X1...Xm, marks X as disposed
(which is not the same thing as deleting the space for X), sends the
new objects to m parallel image sharpeners, which in turn sends their
pieces to the repackager which creates X' and disposes of X1...Xm.

What I want to call attention to is that this business of splitting an
image up and sharpening the pieces individually in parallel is dirty.
There is a lot of room for things to go wrong.  
[snip]
>>>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.
>
>Purely mathematically, if you have only 1-to-1, the resulting graph would
>be a chain of nodes. I doubt it capable to do anything useful.

Ah, an auton can have more than one output port and can do more than
one send.  Similarly it can have more than one input port.  N-to-1
doesn't mean anything if you are lumping all of the input ports
together.

[snip bad actors]

  
>
>You can send messages to an actor from any other actor. That is n-to-1.
>Also I think it is vital to this framework, that an actor does not know who
>was the sender. 1-to-1 would mean that it knows.
>
>Another issue is reuse. If actors as software components are subject to
>reuse, then n-to-1 is a requirement. Components that cannot be reused have
>little or no value.
>
>P.S. I am not going to advocate the actor model here. It is too powerful to
>be safe or efficient.
>
>-- 
>Regards,
>Dmitry A. Kazakov
>http://www.dmitry-kazakov.de

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