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!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.scarlet.biz!news.scarlet.biz.POSTED!not-for-mail NNTP-Posting-Date: Thu, 01 Jun 2006 15:03:43 -0500 From: Ludovic Brenta Newsgroups: comp.lang.ada Subject: Re: task-safe hash table? References: Date: Thu, 01 Jun 2006 22:03:27 +0200 Message-ID: <873beoej8w.fsf@ludovic-brenta.org> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:nA0swDaDXvFSVMcPNaKXIYMEBUQ= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 62.235.57.121 X-Trace: sv3-bmawLGKB8CsrljF3FPGsmCkIqy8aurJTknZFonac+EOgV0dmheGLAzmpkjWvq2T4QfXJr9xYrevYKoE!m1uOgV0Xf0GQ/nuiXitcrf1B4KrWwcI1O7r8eDkiOOOLDAxQYV5UL7G0vG/YcoFYYAaiUe1Z2w== X-Complaints-To: abuse@scarlet.be X-DMCA-Complaints-To: abuse@scarlet.biz 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.32 Xref: g2news2.google.com comp.lang.ada:4639 Date: 2006-06-01T22:03:27+02: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. 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. 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". If you implement the lookup as a function in the protected object, then lookups can be concurrent. I think you should benchmark the actual performance before you decide that it's too slow. -- Ludovic Brenta.