mit krb5 and threads - api

[Barry Jaspan]

>Date: Wed, 03 Mar 2004 02:26:52 -0500
>From: Ken Raeburn <raeburn at MIT.EDU>
>
>Mutexes would be simple -- a thread isn't allowed to lock a mutex it
>already has locked.

In my experience, re-lockable mutexes making programming easier.  If you 
have an API with two external entry points a() and b(), both of which lock 
the object's mutex, but a() is best written by calling b(), what do you do 
without re-lockable mutexes?  Sure, you can split b() up into an external 
locking function and an internal non-locking function, but that is just 
extra bloat, more work for the programmer, it's harder to read and 
understand, etc.  We are already defining a shim layer, and adding lock 
reference counting is really simple.  So why not do it?

>Most of these will be defined as macros.

Haven't we regretted using macros for things in the past?  I don't see the 
advantage.  This is an efficiency hack, and a decent compiler with inline 
hints will optimize code better anyway (let's admit it, krb5 cannot claim 
to have been written with extreme manual optimization in mind).

Barry