| Read James Reinders' counter to this article. |
It's interesting that James would extol the virtues of Ruby on Rails in a forum dedicated to discussing concurrency. Why? Ruby on Rails has done a magnificent job of wrangling the complexity of Web applications into a relatively simple model-view-controller concept, but Ruby enthusiasts know that the technology is embarrassingly nonfunctional when it comes to concurrency.
Describing Ruby's "somewhat cooperative" threading scheduler, the official Ruby wiki notes the language's limitations, most shockingly with regards to the 10ms timeout to guarantee atomicity and allow context switching. "On a high-end system, a 10ms timeslice can be an extremely long time; when running a thousand threads, as might be common in a large massively-concurrent application, it would take at least ten seconds for all threads to get a timeslice. Because of the issues associated with this 10ms timeslice and those associated with green threading in general, concurrency in Ruby is typically achieved by running or spawning additional Ruby processes."
Ruby also boasts some native-incompatible threading features such as the ability to kill threads from anywhere in the program, invoke infinite sleep states and enter critical sections at will.
Benjamin Gorlick has written an informative piece on the challenges of threading in Ruby and the hopes its aficionados have for concurrency support in the future. Rails, especially, "was not designed with multi-threading in mind. It was coded completely non-thread safe. There is no reentrancy in many code paths and there is no good locking on important data structures, especially during development mode. It appears rails core is assuming everyone is going to stuff their servers with as much RAM as possible. I recommend 8-16GB of RAM for applications over ten pages (That was a joke, sort of). The RAM solution works until you reach the point of running a huge installation. Assuming you are using mongrel to serve your rails applications, most developers are coming up with hacks to move logic out of rails so the mongrel processes will be lighter. This is done using basic message queues and partly helps this sort of operation. Small shared hosting applications and small projects really suffer from the rails lack of multi-threading implementation."
New tools are on the horizon, however. Gorlick writes about JRuby, a Java implementation of the Ruby programming language that uses Java threads (generally, native OS threads). "Since Java no longer uses green threads, JRuby is able to map one ruby thread to one OS thread," Gorlick explains. "This means it is truly concurrent and the JRuby team is working to make it more safely concurrent in all the core classes."
Another tool is the Rubinius virtual machine for the Ruby programming language. Loosely based on the Smalltalk-80 architecture, Rubinius is written in C and has several concurrency primitives such as Channels, Actors, Tasks and Threads. "Rubinius is able to create and manage 1000 threads instantly with no noticeable overhead. Java and Rubinius allow threads to run concurrently (i.e., access the heap concurrently) and since Rubinius implements the same way Java does so it should have performance much like JRuby, although there are still potential bugs and missing features," according to Gorlick.
New Analogies: Experts Needed
I realize that James was merely admiring the elegant focus of Ruby, not its aptitude for concurrency. But I find it supremely interesting that Ruby on Rails, like most other programming technologies, now finds itself caught in the concurrency quagmire.
Furthermore, RoR is adapted to an MVC convention because the Web application domain doesn't need too many additional models. Parallelism isn't as limited in terms of domain, platform or applicationit's everywhere.
James's questions bear repeating: Following Ruby's "Convention over Configuration" mantra, what should be the conventions of parallelism be? Certainly, OpenMP and Threading Building Blocks have gone a long way toward standardizing threading code via libraries of common parallel methods. So, are we already achieving CoC, or could there be additional ways to define standard threading and implicit parallelism while forcing developers to specify only their unconventional programming decisions?
With regards to the other Ruby tenet, "Don't repeat yourself," again one could argue that contributions to parallelism libraries are a way to reduce unnecessary labor. But in the context of Ruby, that also means that information is not sprinkled around in hard-to-trace regions of code, but kept in unambiguous repositories. Is there an analogy for concurrency?
Regardless, parallelism solutions can learn from RoR's domain-specific natureeven if RoR needs a push to enter the age of concurrency.
