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!news2.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local02.nntp.dca.giganews.com!nntp.sun.com!news.sun.com.POSTED!not-for-mail NNTP-Posting-Date: Mon, 31 Mar 2008 02:59:02 -0500 Newsgroups: comp.lang.ada Subject: Re: Robert Dewar's great article about the Strengths of Ada over other langauges in multiprocessing! 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> From: Ole-Hjalmar Kristensen Organization: Sun Microsystems Date: 31 Mar 2008 09:59:00 +0200 Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cache-Post-Path: news1nwk!unknown@astra06.norway.sun.com X-Cache: nntpcache 3.0.1 (see http://www.nntpcache.org/) X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 192.18.43.225 X-Trace: sv3-kg47kupGVy7YZ5DtAIVCWiBFxoAGUJYwI37ZZ6P2IYLs4JgQJo4mtVNXGJgTloCL9rb+i67WhtnOZXi!ND0G/RYZZZ1Zf2hCaTHzrGjrqelhfiVi6W9ClXmz+ZblhOrKpLESHejvkJaHYJ6J9DDeUO2XIhwA X-Complaints-To: abuse@sun.com X-DMCA-Complaints-To: abuse@sun.com X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.37 Xref: g2news1.google.com comp.lang.ada:20664 Date: 2008-03-31T09:59:00+02:00 List-Id: >>>>> "FW" == Florian Weimer writes: FW> * Ole-Hjalmar Kristensen: >> Second, I cannot find anything in the RM which says you can make *any* >> assumptions about objects which are outside the protected object so I >> cannot see how signaling will help you. FW> I think that's what 9.10 (Ada 95 without TC 1) is about. Yes, you are right. Thanks. I looked in the part describing protected objects without finding it. 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? 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. -- C++: The power, elegance and simplicity of a hand grenade.