Ksem lifetime?

[Patrick Tullmann]

> Here's another detail that I've been puzzling over while debugging the
> beos-native Ksem implementation: when is a Ksem that isn't explicitly
> destroyed actually destroyed?  Is a Ksem's lifetime co-terminal with
> its "owner", or does it continue existing until explicitly destroyed?

Ksems are allocated one per thread, and should live only as long as
the thread they're associated with.  (Look for ksem in
kaffe/kaffevm/threads.c.)  I think you know this though, so I wonder
if I'm missing the point...  There are iLock objects that are
dynamically allocated, but the threading system never sees those.

> I've been assuming all along that each jthread destroys all of the
> locks that it created itself, prior to invoking jthread_exit.  

Threads (generally) should not exit while holding locks.  While this
isn't entirely true (see the concurrent Thread.destory() topic), it
shouldn't be the responsibility of the threading layer to clean this
up.  (We need to fix the VM layer to protect itself.)

> Is this assumption correct, or should I add code to my threading
> layer that destroys each of a native thread's semaphores immediately
> before the thread itself exits?

You shouldn't have to do this, as the VM-level threading api cleans up
its per-thread Ksems as its threads are destroyed.  I only just
noticed an interesting side-effect of the way Kaffe uses Ksems is that
the "owner" thread is the only thread in the system that will block on
its Ksem.  Also, the "owner" should never signal on its own Ksem, only
the Ksems of other threads.

-Pat

----- ----- ---- ---  ---  --   -    -      -         -               -
Pat Tullmann                                       tullmann at cs.utah.edu
  "You can't have everything.  Where would you put it?" -- S. Wright