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

On Fri, 27 Oct 2000  20:57:03 +0900, Robert Feldt wrote:
[snip]
> 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.

We need a careful definition of the Ruby scheduler granularity here.
Otherwise even an expression like

	if test_and_set(bar) ...

can not be guaranteed to be atomic: reschedule between test_and_set
and if-evaluation. (or is this impossible?)

[..]
> 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).

Hear hear... very nice

> 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

IIUC, this is the abstraction level where my proposal fits in.

If we can avoid new keywords altogether by using :synchronized
notation, that'd be a Good Thing.

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

Same here. Got some catching up to do  :\

IMO a good proposal, thanks.

	Michel