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 X-Received: by 10.182.130.200 with SMTP id og8mr5985048obb.18.1399219476902; Sun, 04 May 2014 09:04:36 -0700 (PDT) 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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!r10no626114igi.0!news-out.google.com!dz10ni31638qab.1!nntp.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail NNTP-Posting-Date: Sun, 04 May 2014 11:04:36 -0500 Date: Sun, 04 May 2014 12:04:36 -0400 From: Peter Chapin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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: <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com> Message-ID: X-Usenet-Provider: http://www.giganews.com X-Trace: sv3-ocQGwGjbCjxf3K96LoSPUoW8ww/krFCtmuX3sFE4pfRma1joNoNy/Nq2NwhrC3kn+Yc6/L1TIkA6boE!DU5jlLEcGybMTYdX/G+cDwclKsMpgVkAL70URbon1/3DkmomcPoIK6xF/sc7334= X-Complaints-To: abuse@giganews.com X-DMCA-Notifications: http://www.giganews.com/info/dmca.html X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 2463 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Received-Bytes: 2769 X-Received-Body-CRC: 3289323372 Xref: news.eternal-september.org comp.lang.ada:19658 Date: 2014-05-04T12:04:36-04:00 List-Id: On 2014-05-04 11:18, sbelmont700@gmail.com wrote: >> 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, 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. I don't think the concern is with the mutex operation itself, but with the possibility of blocking while waiting for the mutex to become available. The mutex operation itself might only take nanoseconds but the wait might be much longer if reads are complex or frequent. Still, it is appropriate to wonder where the application bottleneck would actually be. Networks tend to be slow so if the server is getting hit hard enough to make concurrent reads of an in-memory data structure a concern, the network may have choked long before that. Peter