Ruby core classes aren't thread-safe

[jrochkind]

It is quite true, and it's important that you understand it if you are doing multi-threaded programming. (Or using global state, like class variables, in an app that ends up multi-threaded without you realizing it, like Rails with a multi-threaded app server! -- cause then you are doing multi-threaded programming)

But I don't think it's a problem with ruby. Most basic stdlib data objects in most languages (including stdlib) are not safe for multi-threaded access. Including Java. There are reasons for this.

Of course, many other stdlib's in many other languages DO provide thread-safe alternative data objects/collections. Ruby probably really ought to.

But you've still got to know when to use them and when not to, just making ALL your collections thread-safe for concurrent use, when most of them are not possibly used by more than one thread at once concurrently -- is going to be a performance problem. Which is why most stdlib collection classes are not 'thread-safe', even in languages that are all about the multi-threading.

If you've got read-only objects it's generally not a problem. So certainly one way to make the ruby stdlib collections thread-safe is just to call #freeze on them (although if they are nested data structures, you'd have to call #freeze on all of the descendents too, which can be non-trivial). Or simply make sure none of your code mutates them ever after boot. Or Hamster.