Multithreading the KDC server - a design

[Sam Hartman]

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

    Morrison,> On Monday, April 04, 2005 1:57 PM Sam Hartman
    Morrison,> [hartmans at mit.edu] wrote:
    >> 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.

    Morrison,> Yes, I did not pass on the discussion context when I
    Morrison,> asked for comments.  However, I still think Tom's
    Morrison,> analysis is pertinent.  Even though the goal is for
    Morrison,> multiple execution contexts and not (primarily) for
    Morrison,> multiprocessing, is there a good reason to preclude the
    Morrison,> ability to multiprocess?  Yes, not doing it makes the
    Morrison,> design a bit less complex, 

Yes.  It makes the implementation and initial debugging far easier and does not preclude moving to finer grain locks in the future.


but are we sure that down
    Morrison,> the road we won't need to take advantage of
    Morrison,> multiprocessing?  
Signs point to yes, but no we are not sure.


It seems to me that with a relatively
    Morrison,> small extra effort now, we can leave that option open
    Morrison,> for the future, rather than requiring a redesign later
    Morrison,> if we find that it's necessary.  Why create a potential
    Morrison,> bottleneck if we can avoid it?

Your experience designing locking architectures has been less
problematic than mine.

In general I'm familiar with the strategy of creating large locks and
then later replacing them with small locks as needed.

--Sam