mit krb5 and threads - api
bjaspan at MIT.EDU
Mon Mar 15 09:05:22 EST 2004
>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).
More information about the krbdev