[kaffe] Lock patch
guilhem at kaffe.org
Tue Mar 8 09:58:11 PST 2005
Guilhem Lavaux wrote:
> Helmer Krämer wrote:
>> Guilhem Lavaux <guilhem at kaffe.org> wrote:
>>> I've just finished a functional patch for the locking system. I don't
>>> know yet how much slower it is. But I've already had some interesting
>>> results with some private app which was not working previously. If
>>> noone is against I will commit it on wednesday...
>> If nobody owns the lock, the jthread_t of the current thread is stored in
>> *lkp (afterwards called thin lock). If the same thread tries to lock the
>> mutex again, or another thread tries to do so, a heavy lock will be
>> If *lkp does not point to a heavy lock, a new one is allocated on the
>> To preserve the state of the lock when a thin lock is replaced by a heavy
>> lock, new->holder is initialized with the current value of lk, and
>> is set if necessary. Afterwards an attempt is made to install the
>> heavy lock.
>> If that doesn't work (either because the lock was freed or because
>> thread already installed a heavy lock), the heavy lock is freed and we
>> again with checking whether *lkp is a heavy lock. Once we got a heavy
>> we wait for the heavy lock to become usable by the current thread,
>> just like
>> your code does.
>> What do you think of this?
I've forgotten another thing. I'm wrong not to call gc_free in
putHeavyLock as we are leaking memory at that place (for objects I
mean). If we want to cache the heavy lock we should either follow Tim's
advice or transform the fixed memory allocation by a garbage collected
More information about the kaffe