JRuby Threading
From RubySpec
JRuby maps Ruby threads directly onto Java threads, which are in turn usually mapped directly to OS-level native threads. This essentially has the effect of making JRuby a fully preemptively multithreaded implementation of Ruby.
There has been some debate on the JRuby project whether to additionally implement green threads and the hybrid m:n threading models, to more easily support the thread scheduling semantics of the C implementation. However most of this discussion and design has been postponed since it became clear that Ruby 2.0 would not support green threading.
Scheduling
JRuby does not implement its own thread, deferring to however the underlying Java platform schedules threads. Java platforms, in turn, generally defer to OS-level thread-scheduling semantics. This allows JRuby to avoid implementing a thread scheduler, but also makes implementing thread operations requiring access to or control over the scheduler much more difficult (e.g critical sections, thread killing or stopping, etc).
Control
JRuby implements thread control operations in most cases by deferring to the underlying Java thread implementation of those same operations. For the simple thread operations like yield, join, and sleep, Ruby's operations and Java's operations have roughly the same semantics. However several Ruby thread control operations like critical sections and kill are not supported by Java threads. Various thread events, spinlocks, and atomicity checks must therefore be performed during thread execution by the JRuby runtime to support these operations. Because of the complexity of these operations, JRuby frequently cannot guarantee deterministic killing or criticalizing of threads, since to make such a guarantee would require a sufficiently large enough number of checks on a per-thread basis to effectively cripple all threads. JRuby makes a "best effort" to provide critical sections and to guarantee thread death, but cases can arise where neither of these operations have the intended effect.
