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=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,e0e1d3b3f7c994b8
X-Google-Attributes: gid103376,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news4.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: "(see below)" <yaldnif.w@blueyonder.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: Robert Dewar's great article about the Strengths of Ada over
 other langauges in multiprocessing!
Date: Tue, 01 Apr 2008 15:12:14 +0100
Message-ID: <C418014E.E2483%yaldnif.w@blueyonder.co.uk>
References: <13t4b2kkjem20f3@corp.supernews.com>
 <89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com>
 <fr4916$vo7$1@jacob-sparre.dk> <87bq56peg1.fsf@mid.deneb.enyo.de>
 <wvbrprthzjbf.fsf@astra06.norway.sun.com> <87bq516uri.fsf@mid.deneb.enyo.de>
 <wvbrlk44zf5l.fsf@astra06.norway.sun.com> <87prtfzrtl.fsf@mid.deneb.enyo.de>
 <wvbrhceryy5k.fsf@astra06.norway.sun.com> <87wsnmg1ju.fsf@mid.deneb.enyo.de>
 <wvbrd4pbz5mj.fsf@astra06.norway.sun.com>
 <C4169FA1.E214C%yaldnif.w@blueyonder.co.uk>
 <wvbr8wzyymkw.fsf@astra06.norway.sun.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Trace: individual.net B7GVZVsGQ/ldEP5NiPYTTggdXRcLsyyjmDzKGpaMIi+U05E1YL
Cancel-Lock: sha1:/UD3vv7SzpTGGr5b/JjiD7KFOJ8=
User-Agent: Microsoft-Entourage/12.1.0.080305
Thread-Topic: Robert Dewar's great article about the Strengths of Ada over
 other langauges in multiprocessing!
Thread-Index: AciUAmJLslluQUMkDkSWdV4R670lFA==
Xref: g2news1.google.com comp.lang.ada:20721
Date: 2008-04-01T15:12:14+01:00
List-Id: <comp.lang.ada>

On 01/04/2008 10:02, in article wvbr8wzyymkw.fsf@astra06.norway.sun.com,
"Ole-Hjalmar Kristensen"
<ole-hjalmar.kristensen@substitute_employer_here.com> wrote:

>>>>>> "(b" == (see below) <yaldnif.w@blueyonder.co.uk> writes:
> 
> <snip>
> 
>     (b> I think the wording is trying to cover all the bases.
>     (b> One clue is the phrase "_full_ cache consistency".
>     (b> The caches certainly need to be consistent with respect to the
>     (b> protected data, even for protected functions and procedures,
>     (b> but only entries ensure global consistency and so provide
>     (b> synchronization of data that is not local to the protected object.
> 
> Yes, that seems reasonable.
> 
>>> Btw., I ran a simple test on a SPRAC multiprocessor with an entryless
>>> protected object containing a single integer versus an integer
>>> declared with pragma atomic, and as expected the pragma atomic
>>> solution was much (40x) faster.
> 
>     (b> Unfortunately, we can't usefully apply that pragma even
>     (b> to a pair of integers. (I don't mean the pair's components!)

Also, simply declaring a variable atomic does not in itself
ensure global consistency of view. For that you also need
to execute appropriate memory barrier operations for the
architecture. (I'm sure you know that.)
 
> Agreed, but you may able to cheat and pack a pair of integers into
> a 64-bit atomic, and a compare-and-swap is also much cheaper than a
> protected object it seems.

Yes, but this is completely implementation-dependent.
Not much above the semantic level of assembly.
I would take a lot of convincing that the performance
improvement was actually necessary.

-- 
Bill Findlay
<surname><forename> chez blueyonder.co.uk