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: border2.nntp.dca3.giganews.com!backlog4.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!fdn.fr!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 06 May 2014 14:58: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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <5368dc70$0$6708$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 06 May 2014 14:58:24 CEST NNTP-Posting-Host: 3b283b15.newsspool3.arcor-online.net X-Trace: DXC=:9c@eFT]f_5^cW`WBF>WQ:Lh>_cHTX3j=RdLRheg8gb: X-Complaints-To: usenet-abuse@arcor.de X-Original-Bytes: 4057 Xref: number.nntp.dca.giganews.com comp.lang.ada:186266 Date: 2014-05-06T14:58:24+02:00 List-Id: On 06.05.14 14:19, Dmitry A. Kazakov wrote: > On Tue, 06 May 2014 11:49:01 +0200, G.B. wrote: > >> If the program uses containers only to provide some internal >> storage, then it will naturally shield them. Its own >> data structures (tagged types, say) will only Have-A container, >> and not emphasize the container operations. In this case, I think, >> it is adequate to let the programmer place mutex as needed. >> (Even re-entrant (owned) semaphores incur some overhead.) > > The issues with this low-level approach are multiple: OK, for the sake of a more complete list off issues with either choice: > 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; 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. > 2. A language-supported mechanism does not dictate certain implementation. > The compiler may choose monitor instead of mutex or scheduling technique to > achieve the goal in most effective manner. How could an implementation of task-safe containers be the most efficient choice for all goals? (I'll assume that, since "more effective manner" is rather too vague.) > 3. The low-level approach breaks under inheritance especially when > overriding must call to the parent type operations. Everything can break under inheritance, so that's a rather weak argument, nothing task specific, I think. Clearly, any safe use of anything in a parent operation can be overridden whenever the language allows access. > 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"? Chances are that concurrency control is already associated with the Has-A type, so adding a new operation to it is not different from adding operations at all.