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-Thread: 1089ad,7e78f469a06e6516 X-Google-Attributes: gid103376,gid1089ad,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news2.google.com!news.germany.com!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Embedded languages based on early Ada (from "Re: Preferred OS, processor family for running embedded Ada?") Newsgroups: comp.lang.ada,comp.lang.vhdl 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> <1172239820.896603.222120@k78g2000cwa.googlegroups.com> <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> Date: Fri, 2 Mar 2007 17:32:26 +0100 Message-ID: <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> NNTP-Posting-Date: 02 Mar 2007 17:32:27 CET NNTP-Posting-Host: 01ab642a.newsspool4.arcor-online.net X-Trace: DXC=E@Y6T>=`embOKO]LCQ@0g`4IUKkgbk<797d]g<8n X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:9636 comp.lang.vhdl:7609 Date: 2007-03-02T17:32:27+01:00 List-Id: On Fri, 02 Mar 2007 11:36:22 GMT, Dr. Adrian Wrigley wrote: > On Thu, 01 Mar 2007 14:57:01 +0100, Dmitry A. Kazakov wrote: > >> On Thu, 01 Mar 2007 11:22:32 GMT, Dr. Adrian Wrigley wrote: >> >>> If you don't have multiple processors, lightweight threading is >>> less attractive than if you do? Inmos/Occam/Transputer was founded >>> on the basis that lightweight threading was highly relevant to multiple >>> processors. >>> >>> Ada has no means of saying "Do these bits concurrently, if you like, >>> because I don't care what the order of execution is". And a compiler >>> can't work it out from the source. If your CPU has loads of threads, >>> compiling code with "PAR" style language concurrency is rather useful >>> and easy. >> >> But par is quite low-level. What would be the semantics of: >> >> declare >> Thing : X; >> begin >> par >> Foo Thing); >> and >> Bar Thing); >> and >> Baz Thing); >> end par; >> end; > > Do Foo, Bar and Baz in any order or concurrently, all accessing Thing. That's the question. If they just have an arbitrary execution order being mutually exclusive then the above is a kind of select with anonymous accepts invoking Foo, Bar, Baz. The semantics is clean. > Roughly equivalent to doing the same operations in three separate > tasks. Thing could be a protected object, if concurrent writes > are prohibited. Seems simple enough! This is a very different variant: declare Thing : X; begin declare -- par task Alt_1; task Alt_2; task Alt_3; task body Alt_1 is begin Foo (Thing); end Alt_1; task body Alt_2 is begin Bar (Thing); end Alt_2; task body Alt_3 is begin Baz (Thing); end Alt_3; begin null; end; -- par If par is a sugar for this, then Thing might easily get corrupted. The problem with such par is that the rules of nesting and visibility for the statements, which are otherwise safe, become very dangerous in the case of par. Another problem is that Thing cannot be a protected object. Clearly Foo, Bar and Baz resynchronize themselves on Thing after updating its parts. But the compiler cannot know this. It also does not know that the updates do not influence each other. It does not know that the state of Thing is invalid until resynchronization. So it will serialize alternatives on write access to Thing. (I cannot imagine a use case where Foo, Bar and Baz would be pure. There seems to always be a shared outcome which would block them.) Further Thing should be locked for the outer world while Foo, Bar, Baz are running. So the standard functionality of protected objects looks totally wrong here. > I'm looking for something like Cilk, but even the concurrent loop > (JPR's for I in all 1 .. n loop?) would be a help. Maybe, just a guess, the functional decomposition rather than statements could be more appropriate here. The alternatives would access their arguments by copy-in and resynchronize by copy-out. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de