A Ksem question [Was: Re: changes to thread locking layer]

[Archie Cobbs]

Patrick Tullmann writes:
> alanlb at rrinc.com wrote:
> > I've made the modifications to the beos-native threading system to
> > use Ksems instead, using a simple mapping to native semaphores.
> 
> Cool.
> 
> > Although I've managed to pass most of the regression tests, I've
> > noticed that the ThreadState test program, among others, gets
> > hopelessly deadlocked because the main thread attempts to acquire a
> > lock it already holds.
> 
> Is it an internal lock (i.e., not a Java object lock)?  If so, do you
> know which one?  A backtrace should provide sufficient information.
> 
> > I haven't made my Ksem implementation recursive, because FAQ.locks
> > states that they don't have to be so.  Is this statement still true?
> 
> It should be.  Of course, bugs can break that assumption in all sorts
> of ways.  ;)  I could also be wrong about the non-recursive usage,
> though.

If it should still be true, how about adding an assert() at the
appropriate point in the code?

-Archie

___________________________________________________________________________
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com