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!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx14.iad.POSTED!not-for-mail
From: Brad Moore <brad.moore@shaw.ca>
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: <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>
 <slrnlmcoqd.i0l.lithiumcat@nat.rebma.instinctive.eu>
 <waw9v.109142$f85.65293@fx19.iad> <scy9v.1071029$2N5.142769@fx05.iad>
 <kxy9v.109149$f85.89664@fx19.iad>
In-Reply-To: <kxy9v.109149$f85.89664@fx19.iad>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <9bz9v.1015939$kp1.813341@fx14.iad>
NNTP-Posting-Host: 68.145.219.148
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: 1399242565 68.145.219.148 (Sun, 04 May 2014 22:29:25 UTC)
NNTP-Posting-Date: Sun, 04 May 2014 22:29:25 UTC
Date: Mon, 05 May 2014 16:30:26 -0600
X-Received-Bytes: 2477
X-Received-Body-CRC: 2041040498
X-Original-Bytes: 2719
Xref: number.nntp.dca.giganews.com comp.lang.ada:186229
Date: 2014-05-05T16:30:26-06:00
List-Id: <comp.lang.ada>

On 04/05/2014 3:44 PM, Shark8 wrote:
> On 05-May-14 15:23, Brad Moore wrote:
>> In GNAT any read or write operations on a container that set tamper
>> flags are ironically not task safe
>
> That seems very... odd.

Yes, it seems that the tamper checks are good for adding safety to a 
container object, when that container object is used by a single task,
however the very same tamper checks introduce concurrency problems for
container objects when accessed by multiple tasks.

The setting of tamper checks are of the form;

             B := B + 1;

Where B is a busy flag and is a Natural, without any additional 
protection. Two tasks reading B before the assignment might result
in B only getting incremented once, for instance.

Read operations on the container that might have otherwise been task 
safe, now are not as a result of the added tamper checks.

However, while it might be possible to add protection around the tamper 
flags internally, possibly via a protected object, I think that would
significantly impact performance for containers that were never intended 
for concurrent use. So I think the current GNAT implementation is good 
for the intended purpose.