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
project.
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.
jwm
