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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
