[Ironruby-core] Deadlock issue

Orion Edwards Orion.Edwards at gallagher.co
Mon Sep 5 23:55:59 EDT 2011

I logged an issue on Codeplex (#6449) about the previous deadlock bug I 
encountered, and I have come up with a patch which should fix the issue, 
which I've submitted as a pull request:


To explain the patch:

I did some more research, and it appears as though there was already a 
lock order implicitly specified when locking both ClassHierarchyLock and 
ModuleCacheLock - the hierarchy lock must come first: (refer 
RubyContext.cs line 1051)

I then traced through all the Locks in RubyContext - The majority are 
simple operations and don't require any modification, so I added comments 
I followed the usage of ModuleCacheLock, and made sure the hierarchy lock 
was acquired first if it might need to be acquired in a nested call. 
  - This amounts to a couple of calls to GetOrCreateClassNoLock, which 
requires both the module cache lock and the hierarchy lock

Also added a comment above ModuleCacheLock explaining the lock order, and 
a RequiresClassHierarchyLock to GetOrCreateClassNoLock to clarify these 

I've run some heavily multithreaded test code I have and the changes seem 
to make no appreciable difference to the performance or multi threading 
capability of IronRuby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20110906/bc083c02/attachment.html>

More information about the Ironruby-core mailing list