From: Mike Kasick <mkasick-rt@...>
Date: 2007-07-14T06:54:00+09:00
Subject: Re: Which Hash methods are thread safe?

On Sat, Jul 14, 2007 at 05:53:37AM +0900, MenTaLguY wrote:

> Have you measured to see whether this is actually the case?

Not yet.  Chances are that synchronization won't actually have a runtime
performance impact.  It's just the first time I've worked on a project
where I didn't feel comfortable with requiring so much synchronization
for reading, when in practice, rarely will data actually be mutated.

There's also a scalability concern, however I imagine that the rest of
the application will see scalability issues long before.

> If you'd like to describe what you're doing with the shared Hash, I may
> also be able to give more specific advice.

The one situation I'm working on right now is basically a pub/sub
mechanism on top of drb.  Basically a bunch of clients register a
callback object in a hash (keyed by some client identifier) on a server.
When a message is published, it gets sent to each client registered in
the hash.

The problem with synchronization is that only one message can be sent at
a time.  I could make a copy of the hash value array so that drb calls
don't have to made while synchronized, but that feels like I'd have to
make a lot of unnecessary copies.

Basically the point is that messages are published often, subscriptions
rarely change.  If there was a good r/w lock implementation with
writer's priority, that would solve the problem rather easily.

I guess I could also use Thread.critical= when making subscription
updates, but isn't that deprecated?