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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,16594902ce57591b
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!inka.de!rz.uni-karlsruhe.de!news.belwue.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail
From: "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>
Subject: Re: Multitasking and containers
Newsgroups: comp.lang.ada
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Reply-To: mailbox@dmitry-kazakov.de
Organization: cbb software GmbH
References: <ek6bqd$prc$1@cernne03.cern.ch>
 <b62ajtddi0xt.5azckp3k6y3u.dlg@40tude.net> <ek6hsv$t1o$1@cernne03.cern.ch>
 <143yx0dos45nx.159wpxvfevtt8.dlg@40tude.net> <u8xi1hwk5.fsf@earthlink.net>
 <bFtah.295754$1i1.172141@attbi_s72> <1164623427.5986.11.camel@localhost>
 <YiGah.160827$aJ.83689@attbi_s21>
 <1164656708.657952.123430@j72g2000cwa.googlegroups.com>
 <pan.2006.11.28.01.45.08.406000@linuxchip.demon.co.uk.uk.uk>
 <uvel0qpmi.fsf@earthlink.net> <zq2w04z5om85.1adxu3bs3a773$.dlg@40tude.net>
 <1164730840.554295.78960@h54g2000cwb.googlegroups.com>
 <ew7chqfqaf4k$.q24btvjl13o3.dlg@40tude.net>
 <1164741453.397227.86070@h54g2000cwb.googlegroups.com>
Date: Wed, 29 Nov 2006 19:43:52 +0100
Message-ID: <1n5e3el4so5e4.isypc4vxqcu3$.dlg@40tude.net>
NNTP-Posting-Date: 29 Nov 2006 19:43:44 CET
NNTP-Posting-Host: 0a407211.newsspool4.arcor-online.net
X-Trace: 
 DXC=9SM]dBj@UX5_A0jCfgHO6>4IUK<Cl32<14Fo<]lROoR14nDHegD_]R5_Q_8RlK`I`>DNcfSJ;bb[5IRnRBaCd<M>JXHC7FI0LE3T\m22O:e0Q=
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news2.google.com comp.lang.ada:7752
Date: 2006-11-29T19:43:44+01:00
List-Id: <comp.lang.ada>

On 28 Nov 2006 11:17:33 -0800, Matthew Heaney wrote:

> The issue with hash tables is not the computation of the hash value,
> but rather if the hash function is poor and there are many collisions.
> If that's the case then the time to compare the key to items already in
> that bucket will be large compared to the cost of computing the hash
> value itself.

Yes. This is why one should look into the container, as I said before. You
lock not the container as a whole, but the bucket. The advantage is that in
this case you can lock buckets in a preemptive way, lifting the problem of
too long waits, while loosing little: doubled overhead of a protected
action. This is how our middleware works. Actually it is just a specialized
hash table of process variables. Because it were too expensive to maintain
a lock per bucket, I grouped them into a lesser number of "access
channels."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de