So why is the concurrency in Java 1.4 different of the concurrency in Java 7 (except of a deprecated thread kill function)?
There are two points in concurrency: one is the capability of spawning threads; as opposite to the processes, they share the memory with the parent thread. Processes may share some areas of memory, named shared memory, but this is not implemented in Java either. Second is the synchronization: the ability of a thread to wait for an event caused by another thread (such as signaling, closure, release of a resource), semaphores and critical sections.
It would be great if the author would address these two topics.
Threading is a bit of a moving target in Ruby, especially as between 1.8 and 1.9, and between MRI (Matz's Ruby Interpreter, the original/canonical version) and other implementations, JRuby in particular. JRuby makes use of Java threads, so it can do whatever Java can do, thread-wise. Ruby 1.8 had pure green threads; the whole thread system was written entirely in the interpreter, with no dependence on any underlying OS components. In 1.9, the basic 1.8 thread functionality is there, and there's also support for OS threads if they're present.
The topic that seems to come up the most with regard to Ruby threads recently is the "global VM lock" or "global interpreter lock", which is present in the 1.9 threading model and which, as I understand it, severely restricts true concurrency, because everything has to wait until that one big lock is available. If you want more info on this, and on the work that's going on toward true concurrency, here's an interview with Koichi Sasada, the main architect of YARV, the 1.9 VM.
Ruby training coming up in September! David A. Black and Erik Kastner team up for fast-paced, four-day Ruby intro, in New Jersey, September 14-17. See http://rubyurl.com/vmzN or contact David.
Liar, liar, pants on fire! refreshing plug:
Two software engineers solve most of the world's problems in one K&R sized book