[ruby-talk:5905] Re: [RFC] Towards a new synchronisation primitive

On Fri, 27 Oct 2000, Robert Feldt wrote:

> * We can either introduce new syntax / new primitives into the language or
> choose a simple but sufficient primitive in the language (much like
> Thread.critical today) and then implement mutexes et al on top of that
> (MutexM in RAA is similar to your proposed solution but implemented in the
> current synch model).
> 	* pros with second model is that you can choose the synch
> 	  primitive mostly suited to your needs; there is no one mandated
> 	  by the language.
> 	* cons with sencond model is that people might be tempted to use
> 	  Thread.critical even though a mutex or similar might do, thus
> 	  unnecessarily halting the scheduling / suffering
> 	  performance-wise. (ways to overcome this might be to have Mutex,
> 	  Semaphore, Monitor et al in the standard lib (in the lib ref for
> 	  example) so that they are as visible as Thread.critical)
> 	* lots of more pros/cons...?
> 
Here's a proposal for a refactoring/design of Ruby's thread
synchronization built on a "simple but sufficient" primitive (in order of 
increasingly higher abstraction levels):

1. rb_test_and_set(var)
	Atomic operation (ie. NO scheduling while it runs) for the
        pseudocode:

	int TestAndSet(int *x){
           int temp = *x;
	   *x = 1;
	   return temp;
	end;

        The syntax in Ruby might be test_and_set(x) or something similar.

	This is actually everything that is needed to implement all of
	the other common synch primitives.

	Do not supply Thread.critical= that can stop the scheduler since
        it's both dangerous and might incur unnecessary performance
        penalties. This must of course be weighted against the cost of
        older Ruby scripts using Thread.critical= not working anymore...

2. Implement the common synch primitives (Semaphore, Monitor,
ConditionVariable, what-have-you) using test_and_set. They can even be
written to handle the priority inversion problem since we have
get_priotity and set_priority (alternatively this should/could be in the
scheduler?). IMHO these basic building blocks should be part of the
standard lib and we should encourage people to use them instead of using
the test_and_set directly. To simplify things we can choose one of them
and have it in the standard lib and then have the rest in an
extension (see 4 below).

3. Implement synch/lock on the user-object level using the synch
primitives in 2 above. See for example Masatoshi SEKI's MutexM at
http://www.ruby-lang.org/en/raa-list.rhtml?name=MutexM

4. Implement message queues and the rest of the common multi-threading
helper classes in extension 'multithreading'.

My knowledge of the current implementation of Ruby threads is somewhat
limited though, so I'm not sure how this would affect the deadlock
detection currently available?

Regards,

Robert