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=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Assignment with Adjust and Task Safety Date: Tue, 22 Mar 2016 14:14:40 -0500 Organization: JSA Research & Innovation Message-ID: References: <2c50ad2f-e6d5-4dc9-b4d1-905409311a97@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1458674081 1552 24.196.82.226 (22 Mar 2016 19:14:41 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 22 Mar 2016 19:14:41 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-RFC2646: Format=Flowed; Response Xref: news.eternal-september.org comp.lang.ada:29849 Date: 2016-03-22T14:14:40-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:ncs46a$qo2$1@gioia.aioe.org... ... > You add a mutex, global or of a narrower scope, and take it in Adjust and > Finalize before doing anything else with the pointer. > > I don't do this in my implementation of smart pointers because I consider > it not worth the overhead of two protected actions for being protected > against concurrent access to the pointer. [*] > > The rationale is this. Smart pointers are unlikely shared. Normally they > are kept in containers that are not shared or else are protected by a > mutex, which eliminates the problem. Right. And notice that this performance tradeoff and rationale applies to virtually every library that one could imagine. For instance, it applies to the entire standard Ada runtime. Unless a library advertises that it works with task shared variables (like Ada.Containers.Unbounded_Priority_Queues), one should always assume it does not work without protection. (Usually, a "task-safe" library just ensures that *different* variables can be operated on by different tasks - even that can be hard to support, as in Claw.) For future Ada, we're looking at ways to decrease the danger from shared variables, especially in the context of parallel loops and the like. It is probably the biggest danger in Ada, given that it cannot be tested for (given that very specific conditions have to happen for there to be a failure, the vast majority of the time there is no problem) and that the effects of violating 9.10 can be catostrophic. Randy.