Multithreading the KDC server - a design

[Sam Hartman]

>>>>> "Morrison," == Morrison, Wayne <wayne.morrison at hp.com> writes:

    Morrison,> 2) Section 3.1 says that there will be a single mutex
    Morrison,> used for making the entire KDC code thread safe. This
    Morrison,> may be a HUGE mistake; this is the largest issue I see
    Morrison,> in the document. With only one lock, ALL threads will
    Morrison,> be SERIALIZED by that lock. If you have 20 threads and
    Morrison,> they all need this one lock quite frequently, then
    Morrison,> often only one thread will be running. The amount of
    Morrison,> actual concurrency (on a multiprocessor) may be quite
    Morrison,> low. If this one lock is not used much, then this may
    Morrison,> not be an issue. But the more it is used, the more
    Morrison,> single-threaded and overhead-prone the application will
    Morrison,> be!

    Morrison,> I suggest giving SERIOUS thought to this
    Morrison,> one-lock-for-all design. It might make the entire
    Morrison,> threading exercise yield little benefit.


Hi.  I think this comment comes from missing some conte xt from a
discussion a few weeks ago.  Note that the goal in multi-threading the
KDC is not to take advantage of multiple CPUs.  The goal is to have
multiple execution contexts available so that while one execution
context is waiting for remote database access another execution
context can be processing a request.

To date, we have no real world performance complaints about KDCs
running on moderate single-CPU machines.  I don't mean to imply there
are no performance concerns on the KDC, simply that they are rare
enough we have not heard them.