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=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no 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: Thu, 1 Oct 2020 17:21:01 -0500 Organization: JSA Research & Innovation Message-ID: Injection-Date: Thu, 1 Oct 2020 22:21:03 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="10568"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:60375 List-Id: [Sorry about breaking the thread, my news server can't handle the depth of replies on this thread.] "Dmitry A. Kazakov" wrote in message news:rl543q$1om5$1@gioia.aioe.org... > On 01/10/2020 19:01, Niklas Holsti wrote: >> On 2020-10-01 19:06, Dmitry A. Kazakov wrote: >>> On 01/10/2020 17:38, Niklas Holsti wrote: >>> >>>> If the protected procedures belong to different protected objects, yes >>>> it is legal. But not if they belong to the same object, as J-P noted. >>> >>> But then you have a problem when two independently running protected >>> procedures of *different* objects call a procedure of a third object. >>> You must serialize these calls, and that is effectively blocking. >> >> >> I don't know what you mean by "effectively", here, but yes, one of the >> tasks must wait for the other task to complete the protected operation on >> the third object. So what? > > It looks quite complicated to implement, e.g. checking barriers and doing > locking when you are already done that. > > 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. [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). Randy.