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

On Fri, 27 Oct 2000, hipster wrote:

> Hello fellow rubyists,
> 
> Matz has occasionally expressed his worries about the synchronization
> primitive used in Ruby today. He asked for suggestions regarding alternate
> schemes, and guess what, I wrote one. The following discusses object locks,
> a concept known from Java and others. These object locks would replace the
> current Thread.critical notation.
> 
> I have no prototype implementation of these ideas. This text is intended as
> a basis for discussion to flesh things out.
> 
> I've tried to define things as concise as possible, but given the fact that
> English is not my native tongue, ambiguities may remain. Please abide with
> me.
> 
> 	Michel
> 
I've also been discussing alternatives to the current thread synch
primitives with matz following the bug I found in Queue. Some
ideas/issues:

* 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...?

* Whatever new solution we choose we must be aware of and
probably handle the priority inversion problem, ie. a medium-prio thread
getting processing time when a high-prio thread is waiting on mutex (or
other synch primitive) held by low-prio thread. One good way to solve this
is priority inheritance where the low-prio thread gets the prio of the
high-prio thread while having the mutex lock.

* We should probably start by listing the downside of todays model and
what req's we have on a new one.

Regards,

Robert