Issue #7087 has been updated by shugo (Shugo Maeda).

Category set to lib
Assignee set to matz (Yukihiro Matsumoto)

rklemme (Robert Klemme) wrote:
> shugo (Shugo Maeda) wrote:
> > kosaki (Motohiro KOSAKI) wrote:
> > > monitor is based on Java monitor semantics.
> > 
> > My Java knowledge is rusted, but monitor is not based on Java monitor semantics, at least when it was designed.  Java's monitor mechanism mixes a mutex and a condition variable into one object, but I don't think it's well designed.
> 
> Mutex is not reentrant so there is one reason why Mutex cannot be designed after Java monitor.

I heard the word "reentrant mutex" in the late 90's, but I don't know whether it's Java's invention or not.

> Monitor on the other hand is reentrant and so is synchronize in Java.  Regarding the monitor semantics Monitor and Java's synchronize behave identical.  You are right that Java's monitor also includes a CV.
> 
> >  I guess Java has a better solution (java.util.concurrent.locks.{Lock,Condition}?) now.
> 
> Yes, it's better - IMHO mainly because the user can control how many condition variables he wants to associate with the lock.  Without that you always have to wake up all waiting threads also those who wait for another condition.

Yes, that's why I've separated MonitorMixin::ConditionVariable from MonitorMixin.

> > Monitor has its own version of ConditionVariable.  Use Monitor#new_cond to get its instance.
> 
> I know (see the test program).  But if I use a ::ConditionVariable with a Monitor the error message is irritating.
> 
> > > I would have expected that I can use a Monitor / instance which includes MonitorMixin the same way as a Mutex with ::ConditionVariable.  If that is not intended then I'd rather have an exception TypeError from ::ConditionVariable#wait indicating that a Mutex must be used than the exception about the private sleep method (which happens to be the one from Kernel).
> > 
> > It's not intended, but TypeError is not preferred in Ruby because it breaks duck typing.
> 
> I think that aspect is less important in this case because apparently nobody wants to add sleep to Monitor so ::ConditionVariable will work and also ::CV heavily depends on the passed Mutex's internals so it seems unlikely that there will be another instance usable with CV.

Hmm.... What do you think of it, Matz?

> > I think it's better to add Mutex#new_cond and to make the argument of ConditionVariable#wait obsolete.
> 
> Of course that's an even better solution but it may break existing code - unless you allow #wait to accept 0, 1 or 2 arguments.  With one argument one also needs to check whether it's a timeout value or a Mutex.
> 
> Btw, I am not sure why Mutex is still in the language as Monitor / MonitorMixin seem more versatile.  Do you know why?  Is it to keep compatibility?  We could alias Mutex to Monitor though.

One of the reasons is a historical reason.
In chronological order:

* Ruby had only Mutex, no ConditionVariable.
* I implemented MonitorMixin, MonitorMixin::ConditionVariable, and Monitor as a reentrant mutex.
* Someone (Hara-san?) implemented ConditionVariable for Mutex, but he chose pthread-like ConditionVariable#wait.
  I don't know why.

Another reason may be a performance issue, but I'm not sure.

----------------------------------------
Bug #7087: ::ConditionVariable#wait does not work with Monitor because Monitor#sleep does not exist
https://bugs.ruby-lang.org/issues/7087#change-29935

Author: rklemme (Robert Klemme)
Status: Open
Priority: Low
Assignee: matz (Yukihiro Matsumoto)
Category: lib
Target version: 
ruby -v: ruby 1.9.3p194 (2012-04-20) [i686-linux]


See program attached to bug #7086: timeout_4 always throws:

ERROR: method "timeout_4": #<NoMethodError: private method `sleep' called for #<Monitor:0x87e49f8>>

$ irb19 -r monitor
irb(main):001:0> Monitor.new.method(:sleep)
=> #<Method: Monitor(Kernel)#sleep>
irb(main):002:0> Monitor.instance_methods.grep /sleep/
=> []


-- 
http://bugs.ruby-lang.org/