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: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@instinctive.eu>
Newsgroups: comp.lang.ada
Subject: Re: Safety of unprotected concurrent operations on constant objects
Date: Sun, 4 May 2014 18:07:17 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnlmd0ek.i0l.lithiumcat@nat.rebma.instinctive.eu>
References: <slrnlm6mkg.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com>
 <slrnlmals8.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <lya9aybkxc.fsf@pushface.org> <lk41jr$1vl$1@dont-email.me>
 <slrnlmbs1n.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <6c2cd5d4-a44c-4c18-81a3-a0e87d25cd9e@googlegroups.com>
 <BdmdnZtzY9aJ-PvO4p2dnAA@giganews.com>
Injection-Date: Sun, 4 May 2014 18:07:17 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="76a49b86bc3e16725b7cfca3d85cb4c8";
	logging-data="4983"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX1/MhCsehIy9uZL2p+wZ0q8E"
User-Agent: slrn/1.0.1 (FreeBSD)
Cancel-Lock: sha1:LvLS3W7K7R/I9bA6zp/gx/iPW5c=
Xref: news.eternal-september.org comp.lang.ada:19659
Date: 2014-05-04T18:07:17+00:00
List-Id: <comp.lang.ada>

On 2014-05-04, Peter Chapin <PChapin@vtc.vsc.edu> wrote:
> 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.

Actually my concern isn't the mutex or any bottleneck.

My concern is that right now my application is NOT correct because of
its use of unprotected shared "constant" standard containers. That
situation is NOT acceptable, despite showing no issue on the current
very light load.

So I have to find a solution. And instead of rushing on my text editor
to hack around the code, I first think about potential solutions, and
what are their strengths and weaknesses, before choosing the most
engineering sound.

For example, in some cases the constant map is better replaced with an
array indexed by the result of a function generated by
GNAT.Perfect_Hash_Generators (which I discovered thanks to the research
around this particular problem) than anything mutexed.

I thought such a process wouldn't sound as weird to the audience here...