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: https://github.com/gglresearchanddevelopment/ironlanguages-main/commit/e8be67232d71eb879a1b9487e6fc5e8a93f99266 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 accordingly 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 things. 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>