In message [email protected], surf
[email protected] writes
This paragraph is part of the Java Performance tunning newsletter
someone sent to me. I’m curious what the article means
in regards to threads. My Ruby book has a section
on threads, but I’m not sure if threads in Java are vastly different ?
I’m sure I’ll probably upset someone with this reply, but here goes…
Java threads are roughly equivalent to OS threads. Most JVMs will
implement a Java thread on top of an OS thread. There is no guaranteed
relationship there (just as there is not in .Net) but for practical
purposes it is pretty much valid.
Ruby threads are very primitive compared to OS provided threads. In some
respects the “threading” is more like the cooperative multi-tasking you
found on early Atari ST, Windows (3.1) and Macintosh computers, where
one thread/task could only resume when the current thread/task reached a
point at which the OS could regain control (typically a yield() call or
a GUI event dispatching call, etc - there really was a Win16 yield call
if I remember correctly). That means it won’t take advantage of hyper
threaded or multi core CPUs.
The ruby thread switching is all done by the same OS thread and is done
by a specific function in the ruby runtime (that you don’t call, but the
interpreter does call from certain operations). If that function doesn’t
get called (because the operations that call it are not called) threads
don’t get switched - call a long running C function and your ruby
threads can’t switch until the end of it. Thus the threading effect can
be quite uneven - not pre-emptive like Unix/VMS/Windows operating
If you doubt the above description download the Ruby source and go have
a rummage (all the multi-threaded implementation stuff in the source is
#if defined out).
For full blown threading I guess that won’t happen until Ruby 2.0
(someone else please fill in the details there I haven’t been following
that enough) or the .Dot Net ruby versions (Microsoft and other) where
threading is provided by the underlying .Net Common Language Runtime.
Re: Your Java vs Ruby comment. My preferred languages are C++, assembly
and Ruby. Java always felt like working in a straight-jacket - no access
to the underlying hardware and a restricted way of expressing things.
With Ruby I still have no access to the hardware but a nice language to
do it in. I worked with Java from 1996 until 2005. I’m very pleased I no
longer work with Java.
Even if Ruby (or Python) don’t end up being the dominant
scripting/agile/flexible language in X years time your experience using
it will prepare you for whatever it is that does end up being dominant.