Problems with Mutex and ConditionVariable under IronRuby

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/8d38b629e8ae62d9c4bece398a4041b036d28f12

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

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.

Thanks for a very detailed bug report!

On Fri, Jan 2, 2009 at 17:56, Curt H. [email protected]
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&aid=23408&group_id=4359&atid=16798

On Fri, Jan 2, 2009 at 21:03, Curt H. [email protected]
wrote:

Thanks for a very detailed bug report!

I just filed another bug :slight_smile:

“A Fixnum fails to grow to a Bignum when using the left shift operator”
http://rubyforge.org/tracker/index.php?func=detail&aid=23414&group_id=4359&atid=16798

I tackled this bug when I noticed strange behaviours/errors under
IronRuby while using ruby’s IPAddr class.