Forum: IronRuby Problems with Mutex and ConditionVariable under IronRuby

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Daniele A. (Guest)
on 2009-01-02 14:45
(Received via mailing list)
Hello,

I was playing with threads under IronRuby but it seems like I have
stumbled on problems with Mutex and ConditionVariable. At first I
thought the problem was related to my code even if it actually worked
flawlessy for months under MRI 1.8.6 and it runs fine under the latest
JRuby, so I tried to run the most basic example of using these two
classes (a classic one:
http://www.rubycentral.com/pickaxe/tut_threads.html#UF) but the
problems still persist.

At first I thought it was some kind of deadlock given that the output
obtained by running the code with ir.exe is as follows:

C:\Sviluppo\ironruby\SVN\trunk\build\debug>ir T002.rb
A: I have critical section, but will wait for cv
(Later, back at the ranch...)
B: Now I am critical, but am done with cv

(note that the process remains stuck there)

So I went debugging with Visual Studio and this is what I got in the
output window:
http://gist.github.com/raw/42514/8d38b629e8ae62d9c...

To make it short, the reported exception is thrown when the ruby code
calls ConditionVariable#signal and IronRuby internally calls
Monitor.Pulse on the Mutex instance:

[RubyMethod("signal")]
public static RubyConditionVariable/*!*/
Signal(RubyConditionVariable/*!*/ self) {
    RubyMutex m = self._mutex;
    if (m != null) {
        Monitor.Pulse(m);
    }
    return self;
}

It seems like the Monitor is not aware of being in a synchronized
block of code (or is not in a critical section at all). Any clues?

Thanks,

Daniele
Curt H. (Guest)
on 2009-01-02 18:57
(Received via mailing list)
It looks like ConditionVariable.wait isn't implemented in a way that's
consistent with the spec. Please file a bug report on RubyForge.

I'm a bit surprised by the semantics of this class.  It doesn't appear
possible to use it safely unless there's at least one additional level
of locking.
Daniele A. (Guest)
on 2009-01-02 21:41
(Received via mailing list)
On Fri, Jan 2, 2009 at 17:56, Curt H. <removed_email_address@domain.invalid>
wrote:

> It looks like ConditionVariable.wait isn't implemented in a way that's consistent with 
the spec. Please file a bug report on RubyForge.

Bug report filed.

While I was at it, I filed another bug report about potential
multithreading issues when modules are initialized by IronRuby. See:
http://rubyforge.org/tracker/index.php?func=detail...
Curt H. (Guest)
on 2009-01-02 22:07
(Received via mailing list)
Thanks for a very detailed bug report!
Daniele A. (Guest)
on 2009-01-03 13:17
(Received via mailing list)
On Fri, Jan 2, 2009 at 21:03, Curt H. <removed_email_address@domain.invalid>
wrote:

> Thanks for a very detailed bug report!

I just filed another bug :-)

"A Fixnum fails to grow to a Bignum when using the left shift operator"
http://rubyforge.org/tracker/index.php?func=detail...

I tackled this bug when I noticed strange behaviours/errors under
IronRuby while using ruby's IPAddr class.
This topic is locked and can not be replied to.