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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!news.karotte.org!uucp.gnuu.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: PAR (Was: Embedded languages based on early Ada) Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1172192349.419694.274670@k78g2000cwa.googlegroups.com> <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1c61jqeqo68w$.2irtg70stnsa.dlg@40tude.net> <1vdieyr16h7ct$.1vuvfmghy8dzo$.dlg@40tude.net> <1l5727owshrjf$.uuylbc4ek430.dlg@40tude.net> <45EF1E2B.2020703@obry.net> <1jlhu0mtzerde.1m8xbk8idroav$.dlg@40tude.net> Date: Sat, 10 Mar 2007 10:11:51 +0100 Message-ID: <1q1ocwe0qi51q$.1qsmb4h16h364$.dlg@40tude.net> NNTP-Posting-Date: 10 Mar 2007 10:11:35 CET NNTP-Posting-Host: e8b63b08.newsspool2.arcor-online.net X-Trace: DXC=bo>ADIKg[dbm7>ihJR;B_cA9EHlD;3Ycb4Fo<]lROoRa8kF On Fri, 9 Mar 2007 19:58:53 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:1jlhu0mtzerde.1m8xbk8idroav$.dlg@40tude.net... >> The fine-granularity approach presumes that task-safety could be >> hung on objects later on, i.e. sort of: >> >> declare parallel in parallel -- (:-)) >> I : Integer; -- Same as if it were declared atomic > > I don't believe this statement; I don't see any reason that you couldn't use > the Ada approach with fine-grained parallelism. Because it would not be magical! (:-)) In my understanding the idea of fine-grained parallelism is similar to instruction pipelining. I don't need to care about it when I write an Ada program. I define the constraints in which the compiler/CPU may move (the language semantics) and let them figure out the path they would go. If I had to care about it, that would not be "fine" anymore. >> The problem with the container types (and all other more or less elaborated >> types) is that fine-granularity concurrency does not work for them. That >> was the reason of my original claim that PAR were worth of nothing without >> a feasible concept of synchronization somehow different from protected >> actions and rendezvous we have by now. > > But it surely is possible to design ADTs that *do* work with fine-grained > (and heavy-grained!) parallelism. Sure, the language must be self-consistent, so any forms of parallelism must be mutually compatible. > That requires some locking (I usually use > explicit locks, because I want to control the behavior in ways that > protected objects aren't good at. The locks are safe in that I always use > controlled locks that lock when initialized and unlock when finalized, so > that they don't get held forever if an exception or abort happens). I > certainly agree you can't add that sort of stuff later: it has to be baked > in right away - it's a critical part of the design. The problems with locks are: 1. Semaphores are low-level exposed to the danger deadlocks 2. Priority inversion issues 3. They rely on computationally heavy OS calls and resources 4. Controlled objects used to access locks are slow (OK, that's Ada problem, it need not to be so, and can be fixed) I think that for expressing "magical" parallelism one would inevitably need some "magical" synchronization tools as well... > And if you have parallel-safe ADTs, then fine-grained parallelism should > work, and it ought to be easier to program than traditional Ada tasks, as > there wouldn't be any explicit control flow interactions. So it seems > interesting to pursue... Yes -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de