Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 29 Sep 2011 04:13:27 -0500 From: cri@tiac.net (Richard Harter) Newsgroups: comp.programming Subject: Re: parallel programming Date: Thu, 29 Sep 2011 09:13:15 GMT Message-ID: <4e842854.135345671@text.giganews.com> References: <90b45b75-2a5e-4390-9436-8c5fe5ccd06c@z41g2000yqb.googlegroups.com> <4e7cf020.91690274@text.giganews.com> <11mqgf2emmey1.168vxn0ccau5g.dlg@40tude.net> <4e8333f9.72788007@text.giganews.com> <6zren1hsy8gn.10pqzmgvm8g55.dlg@40tude.net> X-Newsreader: Forte Free Agent 1.1/32.230 Lines: 97 X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-XIz4XG6oFHFshx1ClDyVn+oe/D1cvhmqRJC7GUHP3iLPTcNGUD2Y+WlVF04tU8lOPJbzOBqOalqqqyT!8dFZn8Uma5qdwEtxmOdNoHjt+4vStPvGbUBYStwsYZM+0iNqYy/2EOpF/AxGlBbY X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 5293 Xref: x330-a1.tempe.blueboxinc.net comp.programming:878 On Wed, 28 Sep 2011 20:31:53 +0200, "Dmitry A. Kazakov" 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" >> 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?