Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
>Speaking of counters, that brings me to another issue: Mr Click very
>conveniently avoids the problem with the free of the old table after
>resize since he leaves it to the java gc. It's not that simple for us.
>I guess we'll have to keep similar concurrent access counters for the
>references to the hash table blocks. Even so, it's still not trivial
>to free it in a safe way.
I don't think it's that complicated.
After the copy has completed, the old table doesn't contain any references
anymore, and can be freed without actually traversing it.
>An array of counters is allocated for every thread, and there is a
>function that allocates a counter by returning a free index in those
>arrays. So every thread has its own counter array in the local cache
>in r/w mode, while the others only need (more or less) occasional read
>access. The allocation and freeing of counters should also be
>lock-free, although that's not strictly necessary.
Sounds good.
--
Sincerely,
Stephen R. van den Berg.
"Science is like sex: sometimes something useful comes out,
but that is not the reason we are doing it." -- Richard Feynman
