On Sun, 20 Feb 2000, Richard Levitte - VMS Whacker wrote:
> I seem to recall a comment about how MT locking is done in OpenSSL,
> just a few days ago, on this list.
>
> Anyhow, I've been pondering the caveats of the current locking
> mechanism, which is current done with global locks for each structure
> type. This can become really inefficient if, for example, there are
> several X509 operations going on at the same time with X509 data that
> have no relation whatsoever (at least any memory relation) with each
> other. The comment I saw was that locking should really be per object
> instead of per type, so that several X509 (in this example) operations
> could take place simultaneously.
>
> The drawback with moving locking to be per object is that we would be
> creating a huge amount of them. I can't imagine that it's too bad on
> Unix using pthreads, since those are (as far as I understand them)
> just a memory structure containing some bits of data. However, under
> some other operating systems, like Windows, I understand that mutexes
> are handled through so called handles, and that it's a limited
> resource (a bit like file descriptors on Unix?). I'm sure one can
> cough up more drawbacks...
It's been a while since I spent any time on this with Win32 (oh, more's
the pity - I know) but as I recall it was recommended to use the minimum
number of mutexes you could get away with for this reason - locking
"objects" came at a price and were supposed to be used sparingly.
One possible solution is to use some sort of fake locking. Eg. a recent
posting was to do with multiple threads reading and writing the same SSL
structure. If the SSL structure has a "lock" flag, then applications could
use whatever locking technique they want to synchronise access to that
lock flag. (using ex_data is a bit less straightforward).
I don't think OpenSSL could expect to implement this functionality
directly as I don't think there's a generic solution. Eg. if you use
CRYPTO_LOCK_SSL to synchronise access to each SSL structure's lock flag,
what to do in the case that the SSL's lock flag is currently held? The
CRYPTO_LOCK_SSL needs to be released immediately otherwise things will
deadlock. So an option could be for the thread to usleep() and try again,
to add itself to a locked queue of callbacks and suspend until
interrupted, or whatever. Or real smart-***es could store the thread_id of
the thread currently locking the SSL structure and post a message to it
:-) Dunno.
Perhaps the best idea is to keep the type locking approach that exists now
just to prevent "built-in" race-conditions (reference counting etc.), and
let applications handle locking for race-conditions they may choose to
create (eg. multiple threads using the same SSL object).
I'm wondering how Peter Gutmann's cryptlib handles this issue - it is
thread-safe and all "objects" are handles to structures used internally to
the library. He (and others) must have cracked this nut before ... does
anyone have any "the standard way this is done is ..." references? :-)
Cheers,
Geoff
----------------------------------------------------------------------
Geoff Thorpe Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe http://www.int.c2.net
----------------------------------------------------------------------
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
