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!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Fri, 2 Oct 2020 22:09:19 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Sat, 3 Oct 2020 03:09:23 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="21851"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:60389 List-Id: "Dmitry A. Kazakov" wrote in message news:rl6its$10h7$1@gioia.aioe.org... ... >>> Now let's continue the example. What happens when the calling paths are: >>> >>> O1.P1 --> O3.P3 --> O2.Q >>> >>> O2.P2 --> O3.P3 --> O2.Q >> >> This latter path is always going to deadlock, since the second call to O2 >> is >> necessarily an external call (you're inside of O3, not O2). An external >> call >> has to get the lock for the protected object, and since the lock is >> already >> in use, that will never proceed. > > Is that implementation or requirement? The lock can be task-re-entrant. Language requirement. An external call requires a separate mutual exclusion. If Detect_Blocking is on, then Program_Error will be raised. Otherwise, any pestilence might happen. >> [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. Randy.