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!news3.google.com!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "(see below)" Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! Date: Mon, 31 Mar 2008 14:03:13 +0100 Message-ID: References: <13t4b2kkjem20f3@corp.supernews.com> <89af8399-94fb-42b3-909d-edf3c98d32e5@n75g2000hsh.googlegroups.com> <87bq56peg1.fsf@mid.deneb.enyo.de> <87bq516uri.fsf@mid.deneb.enyo.de> <87prtfzrtl.fsf@mid.deneb.enyo.de> <87wsnmg1ju.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Trace: individual.net 9TWLuiKAksD4NMgJqeY4zAxlhwEbJZdtCHh16hGrcMubrCaCCA Cancel-Lock: sha1:Y0NG3i49fa1ao650NgL/J+qyic4= 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: AciTL5OmGcTUZU5UYkOkhLJVFWAqSQ== Xref: g2news1.google.com comp.lang.ada:20668 Date: 2008-03-31T14:03:13+01:00 List-Id: On 31/03/2008 08:59, in article wvbrd4pbz5mj.fsf@astra06.norway.sun.com, "Ole-Hjalmar Kristensen" wrote: > But one part of 9.10 puzzles me: > > 9.c Reason: The point of this distinction is so that on > multiprocessors with inconsistent caches, the caches only need > to be refreshed at the beginning of an entry body, and forced > out at the end of an entry body or protected procedure that > leaves an entry open. Protected function calls, and protected > subprogram calls for entryless protected objects do not require > full cache consistency. Entryless protected objects are > intended to be treated roughly like atomic objects -- each > operation is indivisible with respect to other operations > (unless both are reads), but such operations cannot be used to > synchronize access to other nonvolatile shared variables. > > If you do not refresh the cache at the beginning of a protected > procedure, how do you avoid reading stale data within the protected > object on a multiprocessor? And why the wording "cannot be used to > synchronize access to other *nonvolatile* shared variables"? Is the > implication that it *can* be used to synchronize other *volatile* > shared variables? I think the wording is trying to cover all the bases. One clue is the phrase "_full_ cache consistency". The caches certainly need to be consistent with respect to the protected data, even for protected functions and procedures, but only entries ensure global consistency and so provide synchronization of data that is not local to the protected object. > 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. Unfortunately, we can't usefully apply that pragma even to a pair of integers. (I don't mean the pair's components!) -- Bill Findlay chez blueyonder.co.uk