From: Joshua Ballanco <jballanc@...>
Date: 2008-12-24T23:44:20+09:00
Subject: Re: Are all Ruby built-in objects thread safe?

On Dec 24, 2008, at 1:56 AM, Just Another Victim of the Ambient  
Morality wrote:

>    I don't think this is relevant.  Concurrency isn't about how many
> processors you use.  Multitasking systems existed long before SMP  
> hardware
> existed.  Concurrency is about doing tasks concurrently.  If you  
> have one
> method running and it may be preempted by another method then they are
> running concurrently.  If the two methods share data then they may  
> corrupt
> that data for each other.  This is true regardless of how these
> concurrencies, or threads, are implemented.  It doesn't matter if  
> they're
> hardware supported system threads or if they're Ruby green threads...

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.

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.

- Josh