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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Tue, 6 May 2014 10:11:07 +0200 Organization: cbb software GmbH Message-ID: <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:19705 Date: 2014-05-06T10:11:07+02:00 List-Id: On Tue, 06 May 2014 00:00:40 -0600, Brad Moore wrote: > On 05/05/2014 10:36 AM, Dmitry A. Kazakov wrote: >> On Mon, 05 May 2014 09:11:05 -0600, Brad Moore wrote: >> >>> Eg. For Ada.Containers.Vectors... >>> >>> type Vector is tagged private >>> with >>> Constant_Indexing => Constant_Reference, >>> Variable_Indexing => Reference, >>> Default_Iterator => Iterate, >>> Iterator_Element => Element_Type, >>> Task_Safe => False; >>> >>> Then programmers could apply the aspect to their own abstractions, which >>> better defines the contract of the subprogram or type. >> >> Task safety is not a type property. Even for a tagged type an unsafe >> operation can be defined later on. For non-tagged types it is even less >> clear which operations must be safe and which not. >> >> Furthermore, task-safety cannot be inherited or composed. At least not >> without massive overhead to prevent deadlocking when two safe types meet as >> mutable parameters of a safe subprogram. > > I agree that such a property is not likely inheritable or composable, > and I don't think we'd want it to be. I think conceivably it could > apply to a type, however. It may be that such an aspect could only be > applicable to tagged types, and only would apply to the primitive > subprograms of that type. The aspect, if true would become false for any > derivations of that type, unless those derived types also explicitly set > the aspect to True. If you limit it to primitive operations then much simpler to do this: type My_Container is tagged ...; -- All operations are unsafe type My_Safe_Container is protected new My_Container with null record; When inherited from, the compiler would override each primitive operation and wrap it with a reentrant mutex taken. When an operation gets overridden its new body is wrapped. Calling operation within a protected action would be bounded error. At least the compiler would be able to maintain mutexes of such objects, e.g. order them to prevent deadlocks. [Better of course, would be to have a decent delegation support] >> And, just how this contract is supposed to be verified? > > I see it more as a contract or promise made by the implementer to the > users of that subprogram that concurrent calls to the subprogram will > work. You can use this contract no more you can verify it. Because the compiler does not know if a call is concurrent or not. > At this point, I have doubts that the compiler could 100% guarantee that > a subprogram call is task safe, but there are likely rules and > restrictions that could be applied that would allow the compiler to > catch many problems. > > In particular, the aspect could restrict the associated subprogram to > disallow: > > (1) Calls on other non-protected subprograms that are not Pure or > Task_Safe; But calling a task-safe subprogram from another task-safe subprogram were a much bigger problem than calling a non-safe subprogram. Protected operations specifically forbid to do exactly this. You could call another task-safe operation only on the same object and only if the implementation deploys reentrant locking. The rules you propose actually are good only for lock-free concurrency. Unfortunately only few things can be done lock-free, and most types of containers certainly not. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de