Are all Ruby built-in objects thread safe?

Robert D. wrote:

I would very much welcome a set of guaranteed-thread-safe wrapper
collections folks could use if they’re concerned about concurrency, since it
would be unreasonable to penalize all code with locking. For now, learn and
love Mutex, or don’t share collections across threads.
That sounds like a fun job. The issue goes well with a question which
burns on the top of my tongue:
How to test thread issues? I do not have any experience in this field
but consider it somehow critical before “promising” functional thread
safe wrappers.

You might want to check out “CHESS: A Systematic Testing Tool for
Concurrent Software” (http://Research.Microsoft.Com/CHESS/) by
Microsoft Research. It is a testing framework for multithreaded
programs (both .NET and native code).

If I understood that correctly, it replaces the operating system’s
threading libraries with its own, so that it can control thread
switching. Then it analyzes the program to figure out every possible
way that the execution streams of the threads can interleave and it
re-runs the program with every possible interleaving.

It actually should Just Work™ if you use either Ruby.NET or
IronRuby to compile your Ruby program to CIL bytecode. (Where “Ruby
program” obviously also can be your test suite.)

Obviously, it would be even better to have a native Ruby version of
such a tool. Rubinus would probably be an awesome base for such a

The problem is in the “determine all possible interleavings” part: I
don’t know whether CHESS uses static or dynamic analysis (or both) for
that; doing static analysis on arbitrary Ruby code might be hard,
probably too hard (in the “equivalent to the Halting Problem” sense).
Static analysis on a restricted subset of Ruby, however, possibly
aided with additional annotations might well be feasible – and you
wouldn’t want to use crazy dynamic metaprogramming in a core data
structure anyway.

Of course, you could also try dynamic analysis.


can invent arbitrary more complex scenarios that would not make any
sense to be covered by a standard method in class Hash.

Well, my point is it’s a bad example. You are asking an object questions
to base your actions on the object on. Don’t ask, tell. :slight_smile:

Put it differently: in concurrent applications there are many scenarios
where lock granularity “method” is insufficient to guarantee correct
code. Instead you need explicit locking for larger portions of client

That might be, I’d like to see a good example.

mfg, simon … i’m not killfiled?

On Fri, Jan 2, 2009 at 9:11 AM, Jörg W Mittag
[email protected] wrote:
I’ll have a look thanx

It is change, continuing change, inevitable change, that is the
dominant factor in society today. No sensible decision can be made any
longer without taking into account not only the world as it is, but
the world as it will be … ~ Isaac Asimov