From: Caleb Clausen <vikkous@...>
Date: 2006-11-08T04:27:06+09:00
Subject: Inter-thread synchronization

At his presentation for RubyConf, Koichi Sasada said that
Thread.critical= may be going away in the future. I stood up
afterwards and requested that it stay. Charles Nutter stood up and
requested that it go. After talking to Charles and thinking it over
for a while, I've decided to withdraw my request to keep
Thread.critical=. It's just too hard to implement Thread.critical=
efficiently and portably on multi-processor systems. (Hardware should
be able to do it, but OSes and JVMs don't support it.)

However, I would like to take this opportunity to open a discussion
about how synchronization should be done in Ruby. Most of what I'm
about to say has been said before on this list, but it's good to
re-iterate it, and try to get some ideas flowing:

All the synchronization mechanisms in thread.rb ought to be re-written
in C. The current ruby versions are too slow. It may be that much of
the current use of Thread.critical= is because Mutex and friends are
so painful currently.

I'm actually of two minds about whether a future ruby that supports
native threads should still have green threads too using the existing
Thread/Mutex/Queue/etc. Usually when making the transition from one to
the other, you want to keep the old interface around for
compatibility. Green threads are generally cooperative, whereas native
threads are preemptive; code written for the cooperative model seldom
works preemptively. However, in the case of ruby, it looks like the
green threads are actually preemptive from the programmers
perspective, so maybe code written for ruby's green threads will work
in a native-threaded implementation.

It would be nice to see some more high-level synchronization
mechanisms, such as read-write locks, priority queues, counting
semaphores, and maybe some kind of select-like facility to wait for
multiple events and/or locks at once.

Also, does anyone know if ruby's threads currently can inherit
priorities? (I'm guessing no...) I've just noticed that they have
priorities, but I don't see anything about priority inversion or
priority inheritance anywhere in the documentation.

Finally, a fairly trivial item. It's somewhat confusing that you have
to require 'thread' and not 'mutex' to get the Mutex class, whereas
Thread is built-in and one doesn't need to require 'thread' to get it
at all (if you can manage without high-level synchronization).