by Patrick Farley
While the Ruby 1.8 and 1.9 internal threading models differ significantly, the exposed concurrency model is fundamentally the same. Unlike Ruby 1.8, Ruby 1.9 threads do map to native threads, unfortunately the 1.9 interpreter forces user created threads to acquire a global mutex lock before executing. The upshot is that 1.9 thread execution is serialized and unable to benefit from multiple cores.
In-process, thread based concurrency is not the only way to effectively chew cores of course. The traditional Ruby approach to utilizing processing power is to spin up multiple isolated process. Rails apps, backed by mongrel or Phusion Passenger processes are the canonical examples. When using this approach, inter-process communication is relatively rare, and done indirectly through shared resources such as a database, memcached instances, or files. Copious real world deployment success stories have proven the efficacy of this approach for occasional inter-process communication. That said, there is a class of application which requires communication between code executing on separate cores at a volume that is only viable via in-process shared memory access. For the time being, JRuby is the best and and only option for building this class of application in Ruby.
