[drlvm][threading] Native locks and thread suspension

[Evgueni Brevnov <ev...@gmail.com>]

Weldon Washburn wrote:
> On 11/25/06, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> On Saturday 25 November 2006 15:23 Evgueni Brevnov wrote:
>> > > > A1) segfault occured
>> > > > A2) grab "system hwe lock" and call vectored_exception_handler
>> > > > A3) instantiate NullPointerException object
>> > > > A4) set up throwing NullPointerExceptionObject in the register
>> snapshot
>> > > > A5) return from vectored_exception_handler release "system hwe
>> lock"
>> > > >
>> > > > Let's next assume that garbage collection was started exactly when
>> > > > thread A was in progress of running NullPointerException
>> constructor.
>> > > > Then, thread A will be suspended while still holding "system hwe
>> lock".
>> >
>> > I see two bad things here. The first one is a violation of  the pretty
>> > known "rule". The rule is don't execute java methods under native
>> > lock. That was discussed several times already. Another problem is
>> > that two threads contend for the one lock while being in different
>> > modes. In other words the first thread gets the lock in suspend
>> > enabled state. The second thread tries to get the same lock in suspend
>> > disabled state. But the first thread is already suspended by GC what
>> > causes a deadlock. Thus it seems like another "rule" for me.
>> >
>> > Any native lock MUST be used either in suspend disabled or suspend
>> > enabled regions. It is prohibited to go outside of the region with the
>> > owned lock.
>
>
> The above seems to make sense.  It might be possible to to add asserts to
> verify the rule is not violated.
>
> I agree with you. It is just not very obvious that the system kernel holds
>> some internal lock when a thread is executing VEH.
>
>
> hmm.... this conversation seems to be mixing DRLVM native code locks with
> locks that are internal to the underlying OS (or  OS provided user-level
> libraries).  Its important to sort out both issues.   Gregory, can you
> clarify?


I didn't think I was mixing these locks. The deadlock which made us
change VEH handler code occurred as a deadlock between kernel internal
lock, and VM lock. Even if we create a facility which would allow to
check (via assertion) the locked/unlocked state of VM locks, it won't
help us when there are locks which we don't control, like in this case.

- Hide quoted text -

> It is windows specific and
>> specific only to some windows versions. We know for sure that windows
>> 2003
>> server SP1 doesn't have this problem.
>
>
>
> I am not sure if it is documented anywhere. We've found the fact that this
>> lock exists in a hard way.
>>
>> > Does the above make sense? Could we somehow ensure this rule with
>> > assert statements?
>>
>> Yes it does. I've always wanted to have a function of Lock_Manager,
>> something
>> like bool is_locked_by_this_thread(). But asserts may be used only on the
>> lock which are controlled by VM. Internal kernel or C runtime locks
>> cannot
>> be
>> checked easily.


--
Gregory