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

On Fri, 27 Oct 2000  06:25:48 +0900, Dave Thomas wrote:
> hipster <[e-mail]> writes:
> 
> > Every instance of class Object (and derivatives) can have a lock, or binary
> > semaphore, associated with it. When a method is called on an object that is
> > declared synchronized, or a method declared synchronized is called on an
> > object, or an object lock is explicitly obtained from within a member
> > method, the object becomes locked. The class or method effectively defines
> > a closure within which the lock is held.
>
> 
> What happens if the method actually generates a closure?
> 
>    def synchronized fred
>      str= "hello"
>      return proc { str }
>    end
> 
>    a = fred
> 
> In this case, will the lock be released when fred returns, or when the 
> proc is garbage collected?

Good point. Possible scenario:
- the proc is created with the self lock held, but nothing more
- the proc inherits the synchronized semantics from fred
- when fred ends, the lock is released
- the proc locks fred upon execution and releases it again
  This requires that procs are passed an implicit first parameter,
  namely `self' (like C++), and are thus tied to a specific instance.
  I don't know if this is already the case.

> > Of course the declaration
> > 
> >   def synchronized foo
> >   end
> > 
> > is equivalent to the explicit
> > 
> >   def foo
> >     synchronize{
> >     }
> >   end
> 
> Possibly not, although I'm not sure. Isn't there a different between
> 
>     def foo(a, b = bar())
>       synchronize {
>       }
>     end
> 
> and
> 
>     def synchronized  foo(a, b = bar())
>     end
> 
> if bar() is itself involved in synchronization?

I'd say the point of definition of a method is at the end of the def
expression, before any method body expressions. Therefore only the
method body is subject to sync-behaviour.

> As 'synchronized' effectively gives us monitors, do you have any ideas 
> on implementing condition variables?

I haven't thought about CVs yet.

> Thanks for an interesting piece: I think this could be an interesting
> thread ;-)

Thank you :)

Another issue for discussion: synced inter-method calls. E.g.:

class synchronized Foo
  def a; end
  def b; end
end

and a calls b. The object lock is already taken, and the rules say all
access is blocked until the lock is free. Deadlock. My first thought
is: allow synced methods to call other synced methods. AFAICS,
atomicity is not hurt.

	Michel