# Deadlock issue

**URL:** <https://www.ruby-forum.com/t/deadlock-issue/211509>\
**Category:** IronRuby\
**Created:** [September 6, 2011, 7:18am UTC](https://www.ruby-forum.com/t/deadlock-issue/211509 "2011-09-06T07:18:01Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [September 6, 2011, 7:18am UTC](https://www.ruby-forum.com/t/deadlock-issue/211509/1 "2011-09-06T07:18:01Z")

</div>

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](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