More ksem fun with the beos-native threading system... (fwd)

[Patrick Tullmann]

> Odd... I sent this to the ML a couple of weeks ago, but it doesn't seem to
> have made it out...

I didn't see anything...   I was hoping the silence meant you'd solved 
the problem.  :)

One suggestion I've got for you is that the gc-lock is a "special
case" lock, with some gross special case code in getHeavyLock().  That
might have something to do with its magic morphing behavior.
Though...  every getHeavyLock() on the gc lock should find the same
address.

> The last portion shows the relative portions from 'ps', plus some info
> garnered from a debugger.  As the comments indicate, you can see one or
> more threads either attempt to acquire a ksem they already hold, or
> release a ksem that they don't hold.

Hmm... maybe "ownership" is somehow being misplaced?  The scheme for
determining ownership of a lock is based on the stack address of the
iLock**, and requires that the threading system correctly report the
current bounds of the thread's stack (if this is wrong, a thread might 
erroneously re-acquire a lock if it doesn't think it already owns it.)
You could probably test for this by adding a new field to the iLock
with the thread id in it, and assert'ing that that is correct...
it would be handy if this sort of debugging info could be turned
on/off easily too...

> It seems to me that one or more of the following are true:
> 
> 1) A trivial mapping of the ksem interface to BeOS counting semaphores doesn't
>    implement the correct ksem semantics.  At the very least, the following
>    are unclear to me:
> 
>      - If ksemGet is interrupted by a system call (as opposed to
>        timing out), is it supposed to keep trying to acquire the
>        ksem, or just return "false" ?  

Three of the four call sites to ksemGet() don't check the return
value.  You might try assert()'ing they actually get the lock.  (I
would guess that a timeout of 0 implies that the ksemGet() should
retry until it succeeds... I think.)

>      - If ksemGet's timeout argument is non-zero, what is the
>        unit of measurement ?

Milliseconds.

>      - Does ksemPut always decrement the ksem's count even if no
>        threads are blocked on the ksem ?

?  That way the wakeup is stored in the semaphore for a later thread
to come along and use...  I'm pretty sure that is the standard
semantics.

> 2) The scheme whereby Kaffe determines whether a lock is being
>    contended or not fails for some reason under certain
>    circumstances.

This would happen if the atomic test+set operations aren't defined or
aren't actually atomic.  Kaffe falls back on a ?: operator in that
case...

> The second one is mere speculation on my part; I'd like to be able to test
> it using a different OS/threading system, but it looks like only my
> beos-native threading system has ksems at all (a conclusion arrived at
> by grepping for "THREAD_SYSTEM_HAS_KSEM") ...

You're definetly the first.  Sorry.  :)

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
		 Does the name `Pavlov' ring a bell?