This is a discussion on Re: Thread safety of MIT Kerberos w/GSSAPI - Kerberos ; 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 ...
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
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.