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!border1.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Safety of unprotected concurrent operations on constant objects Date: Sun, 4 May 2014 07:46:00 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <7403d130-8b42-43cd-a0f1-53ba34b46141@googlegroups.com> Injection-Date: Sun, 4 May 2014 07:46:00 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="23555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19GsCWwKOSy/LUf1WllXjpU" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:ZTB9EnPjX+8Ny9ZUIByV1FU0Vug= X-Original-Bytes: 3934 Xref: number.nntp.dca.giganews.com comp.lang.ada:186203 Date: 2014-05-04T07:46:00+00:00 List-Id: On 2014-05-04, Jeffrey Carter wrote: > On 05/03/2014 02:40 PM, Simon Wright wrote: >> >> Of course those considerations have nothing to do with whether your >> supposedly constant elements are in fact so. > > I have no idea what the OP is asking. Values stored in a container are not > constant. I can't off the top of my head think of anything you can > declare with the reserved word constant that you couldn't read > concurrently. Perhaps an example of the case(s) the OP is worried > about would help. Well, I was worried about standard containers. I lived quite happily in a single-task world, completely carefree with regards to concurrency, until I dipped into web programming through AWS, which introduced to tasking and concurrency hell. I have some shared resources indexed by a string, described in a file, and considered as constant throughout the lifetime of the program (with the standard scheme "restart for changes to take effect"). When I have whatever indexed by a string, I immediately think Maps, and usually go for Ordered_Maps because they are easier to understand. Since the map is semantically constant, I use the magic word constant, with a function to load from file at elaboration, and everything seems to work fine. But then I remembered that a few years ago when I looked at the implementation of GNAT standard containers, they used dirty tricks to write into fields of an "in"-mode parameter, thereby make it not-so-constant. From Simon Wright's post I gather this is still the same. This made me wonder how magic the word constant actually is, so I posted here. I naively expected that since the ARM mandated stuff about shared variable, there would be something in there about shared constant, even though I couldn't find it. I later realized that if the word constant is compromised, then protected functions aren't really protected either, and then there is no way for anything concurrent to happen safely. Considering that any naive container is actually safe for concurrent reads, it was a painful disillusion. 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? and it looks like the answer definitely doesn't involve any standard container (unless there is some corner in the ARM that I missed and that provides some guarantee). Now I admit I haven't actually encountered any problem yet, since I'm the only user of the (very early alpha) web application, with at least seconds between each request, anything non-task-safe would work. But going with "it works for now, let's worry about this later" isn't really in Ada spirit, is it?