From: hipster <hipster@...4all.nl>
Date: 2000-10-27T21:29:29+09:00
Subject: [ruby-talk:5909] Re: [RFC] Towards a new synchronisation primitive

On Fri, 27 Oct 2000  18:12:57 +0900, Hugh Sasse Staff Elec Eng wrote:
> > The proposed syntax requires a new keyword `synchronized', and a new method
> > `synchronize' on class Object. For brevity, the keyword `sync' and method
> > Object.sync could be considered.
> 
> Please don't call it 'sync'.  There is a Unix command of this name
> already, which may cause confusion.  I think 'synch" would be OK though.

Agreed.

> I'm not sure about the need for
> 
>     def synch method
>         ...
>     end
> 
> if an instance can have @variables that are synchronisable. Would 
> that not remove the need to say the method itself is synchronisable?
> It only needs to synch if it touches something "critical".

I'm not sure I completely understand you. If a class is synch, methods
don't need to be explicitly sync'd. Assuming `def synch method' is
equivalent to explitly syncing the method body (discussion pending),
synch is just an alternate notation. I introduced this because matz
spoke about a Java-like synchronized notation/mechanism.

> If 
>     class synch Thing
>         def a
>             b
>             ...
>         emd
> 
>         def b
>             ...
>         end
>     end
> 
> then when a invokes b, it is the same instance that holds the lock, so
> deadlock could be avoided.  The only time you cannot get into your house
> is if somebody ELSE has the only key; if you have it that is OK.  Or is
> that too simplistic?  This area is full of subtleties....

I like this house+key metaphor, let's use it. The Java lang-spec 2.0
uses the same semantics IIRC. And simplicity is good: "Things should
be as simple as possible, but not simpler." -- AE.

Meta: please don't interpret my Java references as if I wanted to
apply the complete Java threading/sync model to Ruby. That would be
bogus. I'd just like to steal^H^H^H^H^Hreuse the clever bits of it.

	Michel