Re: Concurrent trie-hash map

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Jason Thorpe <thorpej%me.com@localhost> wrote:
> 
> I think this is a great thing to add to kern/ as a general facility.
> There are applications beyond just the network stack, as well -- any
> read-mostly hash table that has a lock or an array-of-locks around it is
> a good candidate for being replaced by this.
> 

In such case, unless anybody objects, I will add to src/sys/kern .

It is worth pointing the drawbacks of thmap (trade off for being highly
concurrent): it has a higher memory usage than the hash tables and it is
naturally a bit slower for a single-threaded use case.

> We already have some objects in the kernel that use the "get-ref" /
> "put-ref" pattern for indicating they are being referenced; this is ideal
> for hooking in your G/C mechanism.  We should probably, as a separate
> exercise, extend that pattern to most of the objects managed in our
> kernel (even if the put-ref is a no-op).
> 

Not sure what precisely do you mean by "get-ref/put-ref" pattern here.
In the kernel, thmap would be used with RCU (or passive serialisation
i.e. pserialize(9) API in NetBSD).  It is up to the caller how it would
implement the referencing of the actual objects thmap would store.

-- 
Mindaugas