Re: Are all Ruby built-in objects thread safe?

Joshua Ballanco wrote:
> I think the key here is the granularity of Ruby's atomicity. You're 
> assuming that preemption can occur on the granularity of machine 
> instructions. Were that the case, two simultaneous threads on a single 
> core could, potentially, cause problems. I think what Matz was saying is 
> that, because of the GIL, simultaneous threads will only preempt at a 
> much higher granularity.

And rarely within C-based code, unless that code explicitly yields 
control to the thread scheduler. This also means that calls out to C 
libraries have to be written to use asynchronous calls or they just 
plain block all threads.

In JRuby, threads may preempt at any time, and indeed can and will run 
"really" in parallel at any given time if the hardware supports it.

> So I have a question for Matz and Charles: Would it be reasonable to 
> specify that YARV instructions should be atomic? Charles, how does this 
> work with JVM ops? Last I heard, JRuby was still skipping YARV and going 
> straight to Java bytecodes, which could make this a difficult 
> proposition. My completely uneducated guess, though, is that unless we 
> specify that certain implementation provided data structures must be 
> thread safe (at the very least Mutex), then there would have to be a 
> minimum level at which everything is atomic to be able to write 
> implementation independent thread-safe libraries.

Everything in the thread(.rb) library obviously has thread-safety as 
part of its contract, so you don't have to worry about that. The core 
collections (Array, String, Hash) do not have such guarantees explicitly 
in their contract, and I believe they should stay that way since the 
vast majority of uses are single-threaded. We (JRuby) have additionally 
added locking (as smartly as possible) to ensure that method and 
instance variable tables are thread-safe, since they're crucial to 
Ruby's operation.

I don't think YARV instructions are good atomic units. In JRuby we can't 
even (and won't even) guarantee individual Java bytecodes are atomic. 
Nothing can be atomic unless you lock around it, and in most cases you 
can't have atomicity and still allow code to execute in parallel. Plus 
YARV instructions cover a wide range of things, some of which are 
obviously not atomic like arbitrary method calls or test-and-set (||=, 
&&=) logic. Atomicity and thread-safety should be specified on a 
per-mutator basis for all the mutable structures in Ruby, rather than as 
a blanket assertion.

- Charlie