Thread safety of MIT Kerberos w/GSSAPI

[Ken Raeburn]

On Feb 20, 2008, at 15:01, Jeffrey Altman wrote:
> There should be no need for locking on platforms that support an  
> atomic increment operation which these days should be just about  
> all of the major platforms that we care about.

I've kept that in mind, yes, but so far as I've seen, there don't  
tend to be consistent APIs.  You need different types and functions,  
or sometimes asm statements, for different systems.  And we still  
need to address what happens on systems we haven't found such APIs  
on, or systems we don't care much about but people at other sites do;  
presumably we'd fall back to a counter plus mutex or whatever, which  
means either some kind of wrapper API or big ugly conditionals at the  
use sites.

I'd also rather not just hack something up for the GSSAPI Kerberos  
mechanism (especially just for Windows only) and ignore other places  
where we protect fairly simple operations on data with mutexes.  To  
do it right I'd want to look at some of the other cases, and see if  
we can describe a small set of atomic operations we could take  
advantage of and get rid of a bunch of mutexes.

I'd be careful about removing memory synchronization operations,  
too.  Aggressive compilers and weak-memory-order systems can cause  
some subtle problems to crop up.

Ken