[29336] in Kerberos
Re: Thread safety of MIT Kerberos w/GSSAPI
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Wed Feb 20 15:46:53 2008
In-Reply-To: <47BC86FF.1050906@secure-endpoints.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <5A32A562-D8B4-4D64-A88E-7BCE5C20F3A9@MIT.EDU>
From: Ken Raeburn <raeburn@mit.edu>
Date: Wed, 20 Feb 2008 15:46:23 -0500
To: jaltman@secure-endpoints.com
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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
