mit krb5 and threads - api
raeburn at MIT.EDU
Tue Mar 9 16:22:02 EST 2004
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.
More information about the krbdev