Forum: IronRuby Deadlock issue

D7aaf307f96bbdf5ff39be313fe581be?d=identicon&s=25 Orion Edwards (Guest)
on 2011-09-06 07:18
(Received via mailing list)
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/ironl...


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
This topic is locked and can not be replied to.