Thread safety of MIT Kerberos w/GSSAPI

[Jeffrey Altman]

Ken Raeburn wrote:
> We currently assume that a security context is used in only one  
> thread at a time, so you could switch between threads, just not use  
> it simultaneously in multiple threads.  But the person looking into  
> it earlier concluded that there may not be anything besides the  
> sequence number that's actually subject to race conditions there (and  
> that window's probably small enough that it might "work fine in  
> practice" much of the time, but no promises), so we could look into  
> extending the concurrency for this case, and just do some internal  
> locking around the sequence number accesses.
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.

For Windows you want the InterlockedIncrement function.  There are 
32-bit and 64-bit versions.  The value passed in must be quad aligned.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080220/ed120382/attachment.bin