Hacker News new | past | comments | ask | show | jobs | submit login

What's wrong with the following much simpler construction: each node contains an array of TWO links, and the hash table itself contains an "int link" field.

Readers traverse the chain using the pointer indexed by the link field.

Resizing rebuilds the chains by storing the new links into the 1-link field. When resizing is done, just set link=1-link. The "only" thing you have to guard against are extremely slow readers, i.e., that the table does not get resized twice while a single reader is traversing some chain.

According to the LWN article, concurrent updates with resizing is generally serialized.

What am I missing...? [ya, filling in the details and formal proof of correctness]




Looking at that quickly, I don't see a problem - that should work. Although you're doubling the size of the hash table itself.

You can even do (atomic) refcounting to make sure that everyone is done using the old chain before resizing, although this may slow things down. (So the hash table contains a field of two integers, which indicate the number of readers currently traversing index 0 and 1. Once the value of the "old" index reaches 0, you know it is safe to resize again.)

And you should be able to extend this to k versions easily, which would mean that (k-2) slow readers won't inhibit resizing.

Although, all of that being said, I don't really see the advantage of this over a coocoo hash table.


That works, and has been tested, but would drastically increase memory usage. And you still need a way to track those readers still looking at the previous version, which you'd probably still want to use RCU for.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: