Multithreading the KDC server - a design

[Jeffrey Altman]

My experiences have taught me to attempt to keep the number of required
locks as small as possible to reach the necessary performance goals.
The most common bugs in multi-threaded design are locking issues not
introduced during the initial design but introduced later as additional
code is added to the system by developers who are not familiar with the
lock design.  Either required code is not locked when it should be or
the locks are applied out of order resulting in deadlocks being held.

The initial goals of the KDC threading are to allow for multiple
contexts to be available such that more than one request can be blocked
on a KDB lookup.  As locks should never be held across an I/O operation
I believe that the use of a single lock is the most appropriate first
step.  This will provide the necessary thread safety while allowing us
to remove the bottleneck of the KDC lookups.  Until such time as we have
a further bottleneck to remove, I believe the added complexity will only
get us into further trouble down the road.

I would also like to comment on the use of recursive locks.  "recursive
locks" are necessary when you do not understand your design.  The only
times that I have ever wanted recursive locks is when I am working on
someone else's code and they clearly did not understand the design or
the design was later destroyed by programmers that did not understand
it.  (OpenAFS for Windows comes to mind.)   However, being forced to
work with non-recursive locks will result in a better design and more
efficient code.  "recursive locks" tend to cover up programming errors
so you do not catch them early enough (if ever).  I advise against the
use of recursive locks.

Jeffrey Altman