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!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!newsfeed0.kamp.net!newsfeed.kamp.net!newsfeed.freenet.ag!takemy.news.telefonica.de!telefonica.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 07 May 2014 08:49:08 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects References: <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> <83ha6vuynrzs.1jk08faxb8mnl.dlg@40tude.net> <97a0996a-a593-4990-95e9-44f4e9070fd3@googlegroups.com> <5368b00d$0$6703$9b4e6d93@newsspool3.arcor-online.net> <5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net> <53690cb8$0$6602$9b4e6d93@newsspool4.arcor-online.net> <63k39u59mmk8.eeonyygr5rjc$.dlg@40tude.net> In-Reply-To: <63k39u59mmk8.eeonyygr5rjc$.dlg@40tude.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <5369d765$0$6608$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 May 2014 08:49:09 CEST NNTP-Posting-Host: f4561e1d.newsspool4.arcor-online.net X-Trace: DXC=i1CfXia1Z2H[kmHKHnaEnM4IUKejVHRZPWma2U9cNV?h;:HK0C;I X-Complaints-To: usenet-abuse@arcor.de Xref: news.eternal-september.org comp.lang.ada:19725 Date: 2014-05-07T08:49:09+02:00 List-Id: On 06/05/14 21:14, Dmitry A. Kazakov wrote: >> Manual placement of locks etc. is tedious and prone to >> error. Locking everything is an alternative, but is going >> to annoy those who can show that they do not need everything >> locked, or simply cannot afford the additional overhead. > > If you cannot afford car, there should be none allowed? ("No car" is universally quantified, you did that, I opposed it, asking that there should exist something (in addition?) which is not universally (mut)exclusive, since some programmers may have reasons, and proof of safety, to want otherwise.) >> So you ask programmers who *do* *know* that concurrent reads are >> safe (because they can *show* that concurrent reads are safe) >> to still use mutex and not just read concurrently even though >> the locks are quite unnecessary? > > No, it is you who is asking programmers to re-invent wheel. Programmers may have to use pre-existing wheels (POs, tasks, simpler ...) to compose a solution. In particular, if they do not have magic locking that turns every object into a surprisingly efficient PO. >>> I explained how task-safe primitive operations can be overridden remaining >>> safe. >> >> Here we are: *every* operation of a so protected container >> is run in mutex ways. The programmer does not have a choice. >> It may be the best one, or it may be prohibitively slow. > > He clearly has. If the programmer can request a "protected new" object, and nothing else beside a "protected new" object, in order to make a task-safe program, what are the choices, then? >> No, I don't think I need to expose anything. If the type is derived >> from a parent whose private parts I cannot see, then my derived >> type's operations can only call the allegedly task safe operations of >> the parent type. > > That does not work. Yes, it does, as does Ravenscar (not easy), it just does not follow from only "protected new". Some effort is needed. For example, if my program's type, the one with the container component part, is like "protected new", and the consensus protocol is shown to exclude all tasking issues, my program is task safe. > Task-safety is non-composable. Again a universally quantified statement? If you assume that universal composability is a required feature of every item of every existing program as well as of every potential program, then there is little to left to argue.