Issue #7087 has been updated by rklemme (Robert Klemme).


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

> rklemme (Robert Klemme) wrote:
> > kosaki (Motohiro KOSAKI) wrote:
> > > At least, this is intentional. condtion variable and monitor have different inspiration source.
> > > condition variable is based on POSIX CV and monitor is based on Java monitor semantics. To be
> > > honest, I'm not familiar Java's conditon variable.
> > 
> > For me the difference between Mutex and Monitor is only reentrancy.  Other than that I'd have expected them to be identical (usage and interface).
> 
> 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.

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

> Java's java.util.concurrent.locks.Lock seems to have an equivalent method called newCondition().

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

Author: rklemme (Robert Klemme)
Status: Open
Priority: Low
Assignee: 
Category: 
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/