On 12/4/06, Nikolay Kuznetsov <[EMAIL PROTECTED]> wrote:
Weldon, I've found the cause that resulted in that code to appear.
This one covers the situation when waiting thread being suspended and
notified after that. This code is the part of the patch that prevents
suspended thread from acquiring that lock after notification.
Thanks for the explanation. It seems there are several things going on
here. I think you mean to say, "prevents suspended thread from long term
*holding* that lock after notification". Given the way the code is
structured, a suspended thread acquires then immediately releases the lock.
There is no benefit from the suspended thread thrashing the lock.
I can see that the code provides nicer behavior. The suspended thread does
not hold the lock during suspension but instead acquires the lock once
suspension is lifted.
Is it an issue of complying with the behavior of another JVM
implementation? Or is it a bug that needed fixing? In either case, it
would be much appreciated if you can you point to the regression test(s)
that corresponds to the below.
Nik.
On 12/4/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
> The following code does not look right. I looked in the JVM spec. I
can't
> find any mention that a Thread.suspend() should cause the target thread
to
> give up any java lock. I am trying to construct a test to confirm if
this
> is a problem or not. Anybody have any suggestions?
>
> line 216:
>
>
> if(self->suspend_request) {
>
> hymutex_unlock(mon_ptr->mutex);
>
> hythread_safe_point();
>
> hymutex_lock(mon_ptr->mutex);
>
> }
>
>
> --
> Weldon Washburn
> Intel Enterprise Solutions Software Division
>
>
--
Weldon Washburn
Intel Enterprise Solutions Software Division
