Re: fast mutexes for 1.8?

MenTaLguY wrote:
> On Wed, 2006-11-08 at 17:07 +0900, Joel VanderWerf wrote:
...
>> http://www.rubygarden.org/ruby?ForkableMutex
> 
> Hmm.  Having looked into this, I'm not sure breaking the lock at fork is
> the right thing to do.  The reason is that if fork "kills" a thread
> while it is holding a lock, you have no idea what state the data the
> lock protects is in.

That's a good point. There are special cases where you know the data 
will be consistent. One case is when the other thread has only read 
access to the data. Another is when the other thread has read-write 
access, but does its writing atomically, such as with a single 
assignment to an instance variable.

But, in general, my "solution" doesn't really help. It may in fact 
obscure the problem, because the fork keeps running rather than 
deadlocking when it tries to grab a mutex held by a dead thread.

> As far as I can tell, the only 100% reliable approach is to quiesce all
> threads which might potentially hold locks before forking.

That does seem reliable, but costly in terms of throughput.

In the ruby-talk thread on "thread death callback" I was suggesting 
something a bit different: keep all threads alive in the fork, and raise 
an exception (perhaps a subclass of Interrupt) in all threads except the 
one that forked, so that they can go thru their ensure clauses and in 
particular put the shared data back into a consistent state, clean up 
resources, and then give up locks. Threads need to be aware of this 
possibility and have ensure clauses to handle the cleanup.

-- 
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407