From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a44c40a66c293f3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news4.google.com!news.glorb.com!newsfeed2.telusplanet.net!newsfeed.telus.net!edtnps82.POSTED!023a3d7c!not-for-mail Sender: blaak@METROID Newsgroups: comp.lang.ada Subject: Re: PAR (Was: Embedded languages based on early Ada) References: <1172192349.419694.274670@k78g2000cwa.googlegroups.com> <1172239820.896603.222120@k78g2000cwa.googlegroups.com> <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1c61jqeqo68w$.2irtg70stnsa.dlg@40tude.net> From: Ray Blaak Organization: The Transcend Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Mar 2007 18:16:38 GMT NNTP-Posting-Host: 208.66.252.228 X-Trace: edtnps82 1173204998 208.66.252.228 (Tue, 06 Mar 2007 11:16:38 MST) NNTP-Posting-Date: Tue, 06 Mar 2007 11:16:38 MST Xref: g2news2.google.com comp.lang.ada:9728 Date: 2007-03-06T18:16:38+00:00 List-Id: "Dr. Adrian Wrigley" writes: > Concurrency involving independent operating units without communication is > often straightfoward. There is no communication to screw up - data are read > in parallel and combined serially. This a very common and useful type. Well, sure. It really depends on the nature of what is being computed. My position of treating parallel programming as something that is painful comes about from dealing with concurrent items that do interact with each other. It can get quite difficult to reason that things are correct, that deadlocks and livelocks are avoided, etc. > In my opinion, "par" and "seq" were technically successful in Occam, > and many of the difficult and subtle problems are absent from the > above code because the concurrent units *cannot* address each other. > These parallel constructs are simpler and more restricted than Ada > tasks. The point of "par" is that the restrictions eliminate concerns > over control flow. The issue is checking for erroneous data flow > (eg accidental concurrent updates). The compiler should warn when > this appears to be a hazard. Occam looked fun. I don't think its simplicity would work in Ada, however. But that is not the real point. Adding constructs like "parallel" that make concurrency easier to express in Ada is a good idea. Programmers are free to try and learn how to use them properly. It then becomes a algorithm design and code review issue, rather than a language issue, as to whether the choice of sequential vs parallel was appropriate in any given situation. -- Cheers, The Rhythm is around me, The Rhythm has control. Ray Blaak The Rhythm is inside me, rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.