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!.POSTED!not-for-mail From: "J-P. Rosen" Newsgroups: comp.lang.ada Subject: Re: is there a version of unix written in Ada Date: Fri, 2 Oct 2020 07:36:07 +0200 Organization: Adalog Message-ID: References: <00cd3aaa-d518-43a2-b321-58d6fae70aebo@googlegroups.com> <57eb7a65-51ea-4624-b9dc-9c4dda0fee59n@googlegroups.com> <5f70fd3b$0$13541$426a74cc@news.free.fr> <87wo0d3iac.fsf@nightsong.com> <87sgb02l7b.fsf@nightsong.com> <875z7vyy1u.fsf@nightsong.com> <87wo0bkns3.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 2 Oct 2020 05:36:06 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="b4fd8c57d77b003b02ecb9df47963ac0"; logging-data="6206"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18lY1PBHtKLGsp3ouHSaDBs" User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 Cancel-Lock: sha1:xKe5fhhMyoOb9hErZ+kbcZGa9+A= In-Reply-To: Content-Language: fr Xref: reader02.eternal-september.org comp.lang.ada:60379 List-Id: Le 01/10/2020 à 17:44, Dmitry A. Kazakov a écrit : >> No. Protected objects guarantee that only one task at a time can >> be inside (ignoring functions). Multi-cores don't come into play. > > Inside one protected object, or inside any protected object? Is it > effectively one single protected object and all protected object are > its facets. Inside on protected objects > The scenario is: Task1 calls P1 on O1. Task2 calls P2 on O2. Both P1 > and P2 call Protected_Trace on the protected Tracer object. If tasks > occupy two different cores, would/should one suspend (in order not > use the reserved word "block") another? To continue on Randy's response: mutual exclusion is not blocking. "Blocking" (as in "potentially blocking operation") means "being put on a queue", i.e. when the waiting time is potentially unbounded. The waiting time due to mutual exclusion is bounded by the execution time of the protected operation, and then can be included in the excution time of the waiting task. (In reality, it can be slightly more complicated, but the idea is that it is bounded). >> As surprising as it may seem, allocators/deallocators are NOT >> potentially blocking operations. But I understand your concerns... > > And this raises the same question. Pool must be interlocked, but not > block. What is the semantics of this "non-blocking" interlocking on > a multi-core machine? > Once again, allocators need mutual exclusion, but not queuing, therefore it's OK. > 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. > Waiting, not queuing. -------- In summary, the model of PO is two levels: 1) mutual exclusion, which is not "blocking" 2) for entries: queuing, which is "blocking" Once you realize this, it should make this whole thread clearer.... -- J-P. Rosen Adalog 2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00 http://www.adalog.fr