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: border2.nntp.ams3.giganews.com!border1.nntp.ams3.giganews.com!backlog3.nntp.ams3.giganews.com!backlog3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!rt.uk.eu.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: Wed, 7 May 2014 16:08:26 +0200 Organization: cbb software GmbH Message-ID: References: <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> <5369d765$0$6608$9b4e6d93@newsspool4.arcor-online.net> <1ujfeb1baw6ri.1iprdov55030o$.dlg@40tude.net> <536a1821$0$6706$9b4e6d93@newsspool2.arcor-online.net> <5os0j7jd5moe.1eevhoxwpnpe5.dlg@40tude.net> <536a390c$0$6706$9b4e6d93@newsspool2.arcor-online.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: G+aXx1XI67D34t54ibhUPQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 X-Original-Bytes: 3696 Xref: number.nntp.dca.giganews.com comp.lang.ada:186289 Date: 2014-05-07T16:08:26+02:00 List-Id: On Wed, 07 May 2014 15:45:47 +0200, G.B. wrote: > On 07.05.14 14:14, Dmitry A. Kazakov wrote: >> On Wed, 07 May 2014 13:25:21 +0200, G.B. wrote: >> >>> On 07.05.14 09:40, Dmitry A. Kazakov wrote: >>> >>>> They can even use C. What is the point? >>> >>> The point is that >>> >>> IF programmers want task-safety, and >>> IF programmers need to respect timing, >>> ----------- >>> THEN programmers may need to build safe solutions >>> without "protected new". >> >> I don't see where that follows from. > > "Specification: > > 1. The concurrent program shall access X safely. > 2. It shall do so within at most N µs." This is not a specification and even less a real-world specification (for numerous reasons, I don't want to go into). It is an attempt to bring premature optimization in, by using an imaginary example. Anyway, mutex access has a factor 2 overhead in terms of protected actions. BUT, handling container on the context of a protected action would be a design error in most cases. THEN taking and releasing mutex in Ada is well below 1µs. A read-write mutex has normally greater overhead than plain mutex even in read mode. That means, read-write mutex is deployed only when read operations are lengthy, which is in direct contradiction to your "specification". Lock-free algorithms do not work with most containers. Monitors are in order of magnitude slower than mutex... >> Programmers may need do it without >> dynamic memory allocation, unconstrained types, tasking, exceptions >> whatever. Remove them from the language and anything else they may need go >> without. Then we'll talk. > > Programmers do work in such restricted environments, > for the most part, when using SPARK. Ravenscar was > made to be more efficient than full Ada tasking. > Ada people talk about this. Nevertheless all these features are still Ada, according to the RM. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de