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!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 06 May 2014 18:24:24 +0200 From: "G.B." 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: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <53690cb8$0$6602$9b4e6d93@newsspool4.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 06 May 2014 18:24:24 CEST NNTP-Posting-Host: f1a1ae33.newsspool4.arcor-online.net X-Trace: DXC=J;g2F=n0_b?LNKYb?b>0764IUK:Lh>_cHTX3j= On 06.05.14 17:00, Dmitry A. Kazakov wrote: >>> 1. It is very simple to forget to place mutex in some operation and get a >>> very nasty bug to find. >> >> OTOH, bugs within the task-safe implementation may, as always, >> need fixing by the tool vendor; > > And bugs outside it need not? They sure need that, too, nothing specific here. >> you'd also ask the programmer >> to accept that there is either black (not task safe) or white >> (task safe), but if he chooses white, he has to suppress his >> potential knowledge of a much better concurrency structure. > > I don't even understand what this is supposed to mean. It means that in your model, as I understand it, a programmer gets one of - *no* operations of a container with sharing related add-ons (Ada, as-is) - *all* operations of a container with sharing related add-ons (Ada, with "protected new") See below for when "protected new" is too much wrap. > I pointed out that manual wrapping of operations is tedious, error prone, > and the potential damage is incredibly high as bugs may stay undetected in > the production code for years and there is no way to write a test for such > bugs. Yes. 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. >> How could an implementation of task-safe containers be the >> most efficient choice for all goals? > > By deploying the most efficient method of interlocking available on the > given platform for the given Ada profile. 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? >>> 3. The low-level approach breaks under inheritance especially when >>> overriding must call to the parent type operations. >> >> Everything can break under inheritance, > > This is plain wrong. If everything would break, ("would" invokes the subjunctive conditional, and besides incurring difficulties, is not "can".) "everything will break" /= "everything can break" Conversely, "some things won't break" /= "some things can't break" "Protected new" relates to "some things can't break". "Tagged new" relates to "some things won't break". You had redefined the meaning of "overriding" by stipulating that it means "mutex-wrapping-inheritance". That's OK, though, in real Ada, sadly we don't have that, and whatever a programmer can access in overriding operations, he can use to break things. ("Can", not "would".) If, by analogy, we could have "contract-wrapping-inheritance", then nothing could break either, as long as the contract is good enough and the compiler can supply the necessary contract-based wrapping. > 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. See above. >>> 4. The low-level approach breaks encapsulation. If you add new operations >>> you must expose the mutex to them. >> >> Do you mean "add new operations to the Has-A type"? > > I mean adding an operation, period. This operation, in order to be > task-safe, must use the locking mechanism of the parent type. It could use the parent's locking, but it need not, and this can even be trivially true. (In fact, Ravenscar programs may require that each client call make use of its own lock, as there are no queues.) > E.g. mutex. > It means that you must expose the mutex to make the type publicly > extendable. 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. (Which, by assumption, is my Has-A type, which has a container component, and which itself calls container operations.)