Helmer Kr�mer wrote:
Guilhem Lavaux <[EMAIL PROTECTED]> wrote:
Hi,
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 allocated.
If *lkp does not point to a heavy lock, a new one is allocated on the heap.
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 lockCount
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 another
thread already installed a heavy lock), the heavy lock is freed and we start
again with checking whether *lkp is a heavy lock. Once we got a heavy lock,
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 memory.
Guilhem.
_______________________________________________ kaffe mailing list [email protected] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
