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 21:14:01 +0200 Organization: cbb software GmbH Message-ID: <63k39u59mmk8.eeonyygr5rjc$.dlg@40tude.net> 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: AuYlnUSfTZrfhAkRjyySpQ.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:19722 Date: 2014-05-06T21:14:01+02:00 List-Id: On Tue, 06 May 2014 18:24:24 +0200, G.B. wrote: > On 06.05.14 17:00, Dmitry A. Kazakov wrote: > >> 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. If you cannot afford car, there should be none allowed? >>> 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? No, it is you who is asking programmers to re-invent wheel. >> 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. > 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. Task-safety is non-composable. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de