[Mono-dev] Long term fix for load hook deadlocks

Rodrigo Kumpera kumpera at gmail.com
Mon Feb 16 10:05:33 EST 2009


Hey,

I've spent some time last week on this subject trying to see how this could
be fixed.

My initial idea was to remove the loader lock from all paths that lead to
managed code
been called. Thou it's possible, it would require some very complex changes
to class loading
to support System F recursive type definitions (F : T<F>) in a way to do
safe publishing.

It would buy us more trouble than anything else. Which turned my attention
into fixing ther
other locks instead. Besides the loader lock, only two other are held during
complex interactions
with the system: the domain and domain jit code hash locks.

My idea is to change the locking rules to make the loader lock the bottom
one, this would
make it safe to call managed code while holding it and it's not much
different than what currently
happens.

Both other locks, domain and domain jit code hash are used most of the time
just to protect
resources that are part of MonoDomain.

The issue then would be to rework the part of the runtime that hold the
loader lock together with
the others. All code in metadata can be changed pretty easily as it acquires
one after the other.
The trouble is in mini.c where the interaction between those locks is pretty
complex but changing
it isn't that that hard.

This approach would require us to split all the uses of the loader lock to
protect resources such as the
the uiid table as this is a task for simple locks and might have a bad
interactions with other parts of the
runtime.

Comments?

Cheers,
Rodrigo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090216/ab1838fc/attachment.html 


More information about the Mono-devel-list mailing list