From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Sat, 3 Oct 2020 13:44:47 +0300 Organization: Tidorum Ltd Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: individual.net M9AjK8k1U4AZ3az/LK3q8Q2Bv1hqSvBjJJJwJcuh4k1YVyjXGO Cancel-Lock: sha1:cbgYbfIksV7mLFzUvvbCIY9WXI4= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:60400 List-Id: On 2020-10-03 11:16, Dmitry A. Kazakov wrote: > On 03/10/2020 09:44, Niklas Holsti wrote: >> On 2020-10-03 9:42, Dmitry A. Kazakov wrote: >>> On 03/10/2020 05:09, Randy Brukardt wrote: >>>> "Dmitry A. Kazakov" wrote in message >>>> news:rl6its$10h7$1@gioia.aioe.org... >>> >>>>>> [If O3 was nested in O2, then the second call to O2 could be >>>>>> internal. >>>>>> But in that case, the first path would be impossible as O1 could >>>>>> not see O3 >>>>>> to call it.] >>>>>> >>>>>> Remember that the decision as to whether a call is internal or >>>>>> external >>>>>> is >>>>>> purely syntactic: if a protected object is given explicitly in the >>>>>> call, >>>>>> one >>>>>> needs to trigger the mutual exclusion mechanisms again. The only >>>>>> time one >>>>>> doesn't need to do that is when the call does not include the object >>>>>> (that >>>>>> is, directly from the body of an operation). >>>>> >>>>> Even when the object in the call is statically known to be same? >>>> >>>> Yes. An external call *always* gets the lock again. I believe that >>>> was made >>>> the rule to make it obvious as to what will happen based on the form of >>>> call. >>> >>> I mean this: >>> >>>     protected body O is >>>        procedure P1 is >>>        begin >>>           ... >>>        end P1; >>>        procedure P2 is >>>        begin >>>           P1;   -- OK >>>           O.P1; -- Deadlock or Program_Error >> >> >> That is an internal call, so no deadlock nor error. >> >> See RM 9.5(4.e), which is this exact case. >> >> >>>        end P2; >>>     end O; > > I.e. it is *not* based on the syntax of the call. At least not on /that/ syntactical difference. > Anyway the rather disappointing result is that protected procedures may > deadlock (or Program_Error) in a legal program. Legal program can run into all sorts of problems, starting with use-before-elaboration. > So my initial disinclination to jump from one protected object to > another is a reasonable advise. Quite conservative advice, though. > Or at least the order in which protected > objects are navigated must be same. I would say that it is advisable to arrange the POs (or PO types) in a layered architecture and make inter-PO calls only from a higher-layer PO to a lower-layer PO.