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,4cf1fd41f64f8f02 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!atl-c08.usenetserver.com!news.usenetserver.com!pc02.usenetserver.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail Newsgroups: comp.lang.ada Subject: Re: task-safe hash table? References: From: Stephen Leake Date: Fri, 02 Jun 2006 06:35:10 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:SrKiK0CcW8rI1yIKhHRH1rI8ZuQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@flashnewsgroups.com Organization: FlashNewsgroups.com X-Trace: 8e46d4480146ae73ae4a405851 Xref: g2news2.google.com comp.lang.ada:4647 Date: 2006-06-02T06:35:10-04:00 List-Id: tmoran@acm.org writes: >> > I think you might be able to get part way by consulting the original >> > Booch components. >> >> The 95 BCs were going to have Synchronized and Guarded extensions, but > The app I had in mind was the k-nucleotide shootout benchmark, which > uses a hash table, running on a multi-core cpu. If lookups are read-only, > and are much more frequent than writes, one should be able to do them > concurrently. Since a lookup in a hash table is, presumably, pretty fast, > the overhead of making it Protected would probably kill the gain. What "overhead"? The whole point of the ceiling priority protocol on protected objects is that they are cheap to access. I'm not entirely sure what that means in a multi-processor setting, but it should be at least as fast as any other mechanism. > But one ought to be able to arrange things so a concurrent lookup > that comes back with a hit is correct, ie most of the time, while > one that comes back "we need to add this" would be rare enough that > interlocking for a second check and possible add wouldn't cancel the > wall clock savings. That sounds perfect for a protected object, with a function for read/lookup, and a procedure or entry for write/add. > So this is a very specific test to see what Ada tasking, on a modern > chip, buys you on this particular app. (I already know it's a win on > the word count and on a sort.) I'm just hearing too many people say > "multi-core is dumb because nobody knows how to do concurrent > programming". Yes, it would be good to show that Ada helps on this type of problem. -- -- Stephe