From: Eivind Eklund <eivind@...>
Date: 2004-02-25T06:08:11+09:00
Subject: Re: rehash segfault

On Wed, Feb 25, 2004 at 03:30:54AM +0900, Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "rehash segfault"
>     on 04/02/25, Nathaniel Talbott <nathaniel@talbott.ws> writes:
> 
> |I don't have a lot of information on this bug at this point, but 
> |figured I'd throw out what I do have, and see if it's enough to jog 
> |someone's brain. I'll of course continue to gather more information as 
> |I'm able and present it here.
> |
> |I have code that looks like this in my application:
> |
> |   @cache = Set::new
> |   def @cache.rehash
> |     @hash.rehash
> |   end
> 
> Ruby hashes are not completely thread-safe.  I knew the problem
> existed, but I couldn't fix it without significant slow-down.

What is the exact problem that makes it hard to fix without slowdown?

The non-safe part I noticed was the rehash free and then reset the hash
without seeing if the hash is quiescent.  Setting it first and freeing
it afterwards would reduce the problem slightly; a quiescing operation
(yielding the CPU) would basically solve it under the assumption that
the threads are all in-core and get enough time to be able to finish a
lookup inside a single quantum.  Writers would still need to lock, of
course.  I have a feeling this may also be possible to eliminate (I've
done it for linked lists before), but I'm not 100% certain.

Of course, if we can't make the assumption that we're able to get
through a single lookup inside a quantum, it is probably necessary to
use a fully locking implementation.

Eivind.