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!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed-0.progon.net!progon.net!newsfeed.ision.net!newsfeed2.easynews.net!ision!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
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>
 <uslcxt1u7.fsf@stephe-leake.org>
 <1172239820.896603.222120@k78g2000cwa.googlegroups.com>
 <u649rx29a.fsf@stephe-leake.org> <nhn5b4-9b2.ln1@newserver.thecreems.com>
 <pan.2007.02.24.22.11.44.430179@linuxchip.demon.co.uk.uk.uk>
 <u7iu68eba.fsf@stephe-leake.org> <es4dl5$ve2$1@newsserver.cilea.it>
 <pan.2007.03.01.11.23.01.229462@linuxchip.demon.co.uk.uk.uk>
 <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net>
 <pan.2007.03.02.11.36.51.700020@linuxchip.demon.co.uk.uk.uk>
 <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net>
 <uvehjjdff.fsf@STRIPCAPStelus.net>
Date: Sat, 3 Mar 2007 12:00:18 +0100
Message-ID: <1c61jqeqo68w$.2irtg70stnsa.dlg@40tude.net>
NNTP-Posting-Date: 03 Mar 2007 12:00:01 CET
NNTP-Posting-Host: b4d2b375.newsspool4.arcor-online.net
X-Trace: 
 DXC=_XOgZeCf;=G0YVY]kmLTlD4IUK<Cl32<A4Fo<]lROoRA4nDHegD_]RE]g44KB4=oEGDNcfSJ;bb[EIRnRBaCd<MN1K:SL4f2T?GWZck;;@Z`CO
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:9649 comp.lang.vhdl:7615
Date: 2007-03-03T12:00:01+01:00
List-Id: <comp.lang.ada>

On Sat, 03 Mar 2007 01:58:35 GMT, Ray Blaak wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>> 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. 
> 
> I am somewhat rusty on my Ada tasking knowledge, but why can't Thing be a
> protected object?

I tried to explain it in my previous post.

When Thing is a protected object, then the procedures and entries of,
called from the concurrent alternatives are all mutually exclusive. This is
not the semantics expected from PAR. Probably it would be better to rewrite
as:

   declare
      Thing : X;
   begin
      par -- Though this appears concurrent, it is not
         Thing.Foo;
      and
         Thing.Bar;
      and
         Thing.Baz;
      end par;
   end;

> It seems to me that is precisely the kind of synchronization control mechanism
> you want to be able to have here.

No. The implied semantics of PAR is such that Thing should be accessed from
alternatives without interlocking because one *suggests* that the updates
are mutually independent. When Thing is visible from outside it should be
blocked by PAR for everyone else. This is not the behaviour of a protected
object. It is rather a "hierarchical" mutex.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de