Re: [Sablevm-developer] Threading support in SableVM

[Archie C. <ar...@de...>]

Chris Pickett wrote:
> As a side note, Etienne, it seems strange to me that under contention, 
> you don't inflate the actual thin lock being released in your algorithm, 
> but you inflate all of the other locks that the thread owns.  I think it 
> means that if two threads were competing for just one lock, it would 
> never get inflated.

It's not necessary to inflate the thin lock. If thread #1 owns it
and thread #2 contends for it, thread #2 sets the contention flag
and puts itself on thread #1's queue. Thread #1 will wake up thread
#2 when it releases the lock (after seeing it in the queue), and then
thread #2 will acquire the thin lock. Only if thread #1 sees threads
waiting on *different* objects must thread #1 inflate the associated
lock.

In effect, the condition variable associated with thread #1 itself
(env->contention.requester.cond) functions as the monitor in this case.

I.e., if you didn't care about efficiency, you could just never
inflate any locks, and instead rely on the owning thread's condition
variable. But then you'd have efficiency problems in cases where
one thread owned a bunch of different locks at the same time -- all
other threads waiting on any of the held locks would get woken up
anytime any one individual lock was released by the thread. With
the hybrid thin/fat lock scheme, only the threads that ever should
be woken up are.

The inflating of the "other" locks is to avoid this inefficiency.
But it's not necessary to do this for threads waiting on the actual
lock being released, because you do indeed want those thread to
wake up.

(This is my understanding, Etienne please correct if necessary...)

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com