mit krb5 and threads - api

[Ken Raeburn]

On Tuesday, Mar 9, 2004, at 15:29 US/Eastern, Jeffrey Altman wrote:
>> Mutexes would be simple -- a thread isn't allowed to lock a mutex it
>> already has locked.
> Is there a reason we are making this requirement?

I figured it would be simpler.  If a non-pthread system offers only 
simple mutexes and we assume reentrancy, reentrant mutexes would have 
to be constructed on top of them.  If it offers only reentrant mutexes 
and we code to the assumption that they're simple (and note that 
there's no trylock operation), the only effect should be that we lose 
some error checking.

> Are we planning on implementing our own mutexes?
> If so, will these mutexes be global to the system or
> to the local process?

No.  Well, not exactly.  For testing purposes, I'm currently wrapping a 
POSIX mutex up with some debugging data, like the file and line number 
where it was last locked or unlocked, flags indicating whether it's 
been initialized and locked, and I've got assertion tests before the 
pthread calls to try to force core dumps in any broken code.

They'll be local to the current process only.  No global mutexes.  If 
someone wants to implement them for a library hack that shares data 
across processes (a shared memory segment ccache? replacement for file 
locks?), they're welcome to do so, but that's outside this basic 
locking scheme for in-memory data structures.

> OpenAFS has run into some problems because developers
> make the assumption that mutexes can be safe locked
> twice within the same thread.  This has lead to some
> interesting deadlock situations which are difficult
> to debug.

Sounds like another good reason to require simple locks.

Ken