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: Thu, 27 Mar 2008 04:31:52 -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> From: Ole-Hjalmar Kristensen Organization: Sun Microsystems Date: 27 Mar 2008 10:31:50 +0100 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-3lWZ4lAk1Ckf5IlJ50DeI1s3GI5GHUaqaDlCjE2XU/Io7+6h4sCJ7ZXBPHcpY66ca/Geign2DIR24Er!HAlGj7ktbLOcW/t2D4zTmlEdpUDBCl2rKFPkqK9eqOYa7c8Crb4USU1V8BvIEpjiDvaBHdchBNMT 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:20601 Date: 2008-03-27T10:31:50+01:00 List-Id: If you mean that it may be difficult to optimize, I agree, but I cannot agree that you need *more* than an entryless protected object to implement a hash table, since it guarantees that each operation on the object is indivisible. The simplest case (for the programmer) is of course to put both key and value inside the protected object, Then a reader will either see the key, value pair as it was before the update or as it is after the update. The problem is that although reads within a procedure may be optimistic, the compiler probably needs to insert at least a spin lock during the actual update of the object. What I was thinking of was to recognize the special case where the entryless protected object contains only a single entity which can be updated atomically with a compare and swap. In that case, you could skip the spin lock in the update phase and use CAS directly. In this case the key and the value would be in separate protected objects, and the implementation of the hash table could follow the pattern of the hash table you mentioned. On the other hand, I cannot see any reason why Annex C just couldn't say that intrinsic subprograms for compare-amd-swap and similar machine operations shall be provided *if* they are available on a platform. That would at least save me the work of writing the bindings myself. >>>>> "FW" == Florian Weimer writes: FW> * Ole-Hjalmar Kristensen: >> If the compiler is smart enough to optimize this case, an entryless >> protected object would be a good building block. >> >> The AARM states that "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" FW> You need some signaling for a shared hash table, otherwise reading a FW> freshly-added object from a different thread might not give you the data FW> you want (strictly speaking, even just comparing the might cause FW> issues). -- C++: The power, elegance and simplicity of a hand grenade.