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: border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx19.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (Windows NT 6.1; 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1399230236 68.145.219.148 (Sun, 04 May 2014 19:03:56 UTC) NNTP-Posting-Date: Sun, 04 May 2014 19:03:56 UTC Date: Mon, 05 May 2014 13:04:57 -0600 X-Received-Bytes: 4177 X-Received-Body-CRC: 2658063373 X-Original-Bytes: 4419 Xref: number.nntp.dca.giganews.com comp.lang.ada:186214 Date: 2014-05-05T13:04:57-06:00 List-Id: On 04/05/2014 9:57 AM, Natasha Kerensikova wrote: > On 2014-05-04, sbelmont700@gmail.com wrote: >> On Sunday, May 4, 2014 3:46:00 AM UTC-4, Natasha Kerensikova wrote: >>> >>> So I guess to correctly frame it as a question, that would be: how can I >>> >>> have a map capable of concurrent reads with minimal wheel reinvention? >>> >> >> You really can't. You can either reinvent the wheel in your own >> task-safe manner, > > I find it extremely hard to believe that there is no such wheel existing > out there. Standard containers and Booch components might not fit the > particular requirements, but I would bet there are some existing container > implementations that fit. I believe as long as the use of the container involves only read operations (functions with in parameters), it should be safe to use concurrently. Yes, these read operations typically involve modifying the container (to implement tamper checking), but is done in such a way to allow safe concurrent access (at least in the implementations I have tried). If done carefully, concurrent write operations on a container are also possible. For example, I can provide an example in GNAT of incrementing all elements in an integer vector container with parallel execution, without any added protection or synchronization. Each worker is only updating elements in its assigned range of the vector, via Replace_Element. In the GNAT implementation, Replace_Element doesn't set any tampering flags. It only checks for tampering, which might happen if another call such as Iterate was executed concurrently. Since the only call happening during the parallel execution is Replace_Element, it works. That being said, I didn't have any luck finding wording in the RM that guarantees safe concurrent use of a constant object of a language-defined container object. While it likely is safe to do so, if you are looking for a guarantee, the RM does not appear to provide one currently. It might be that this clarification could be added to the RM relatively easily, provided that implementers agree that such a clarification wouldn't cause too much of an implementation burden. > >> or assume-the-worst about the standard map and surround it with a >> mutex. Though, as was said, the split-seconds you would burn on the >> mutex would be negligible when compared to the network delay of >> supplying the results. > > How would you "surround it with a mutex"? Do you mean a procedure in a > procted object, or some other scheme I'm not familiar with? > > However, if I start assuming the worst about standard containers, I > might soon slip down the slope towards assuming the worst about all > others standard features. There is nothing in the ARM that prevents tag > checks or dispatching from being implemented through a splay tree or > some other concurrent-read-unsafe mechanism, is there? Should I mutex > those too then? >