[kaffe] Kaffe fast locks against slower locks

[Guilhem Lavaux]

Hi,

I've been quite busy these latter days so I haven't yet a patch ready 
for locks. Here is a summary of the problems/solutions:

* currently kaffe uses a fast lock mechanism which needs to work to get 
a unique pointer for each thread. These pointer represents the holder. 
The stack pointer is a good candidate and it gives also the possibility 
to handle quickly recursive locks (when there are not contended).

* However there are two drawbacks (at least):
1) getHeavyLock is really slow because it uses a ksem semaphore in 
timeout mode. It also looks to me a bit unreliable because this is the 
same semaphore that is used for waking up locked threads. So the wrong 
thread may be catching the signal (I haven't really analyzed fully the 
code at this place so it may not be the case but a timeout is really bad 
anyway for a lock).

Solution: use a specific heavy semaphore lock however all threads must 
be aware of it at the time it is used.

2) More problematic I've noticed that the JNI calls MonitorEnter and 
MonitorExit uses lockObject and so the stack pointers to handle 
recursive locks. This is not _right_ and even buggy in most cases as the 
stack is rewinded when lockObject exits. The specification says also 
that we must really take care of the number of times monitorenter has 
been called.

Solution: use a real counter and not the stack pointer as the fast lock 
mechanism does not track the number of times MonitorEnter and 
MonitorExit has been called.


Consequence: Either we use a standard pthread lock mechanism and locks.c 
transforms into a simple adaptative layer for jmutex_* and jcondvar_* 
functions (and so we must update jthreads' functions because they do not 
support recursive locks), or we keep the ksem implementation but 
implement a "not so fast" locking mechanism with also two layers 
(contended and not contended) and we give up stack pointers handling.

I have already begun modifying locks.c in case we're ok to keep ksem's 
implementation.

Any suggestion ? Any problems ? Any improvements ?

Cheers,

Guilhem.