If you are only worried about system resources for locks, a two tiered
locking system might be appropriate. The upper tier, the system locks, can
be keyed off of groups as they are now. The second tier protects actual
objects and can be memory resident. You must own the group lock in order to
try to grab the object lock ( releasing the lock is always permitted).
Whether or not the access to the object lock is successful, the group lock
is released. This minimizes contention for locks. The mechanism for retrying
a failed attempt to get an object lock should preferably work on some sort
of semaphor system so that a thread does not hog the cpu while waiting for a
resource to become free. I can discuss the model off line with anyone
interested.
> -----Original Message-----
> From: Richard Levitte - VMS Whacker [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, February 20, 2000 9:58 PM
> To: [EMAIL PROTECTED]
> Subject: MT safety and global locks
>
> 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...
>
> Steve, can you confirm/deny what I just wrote?
>
> Anyone, the above is thoughts about what can be done with OpenSSL to
> connect the objects with their locks, making them single protected
> areas instead of protected in group. Should we take such a thing in
> consideration? Other comments?
>
> (and yes, I know, that will be a HUGE change, and will break some
> operations (most specifically, all those who currently use the CRYPTO
> lock routines. On the other hand, those can still be supported, just
> not used internally... I think...).
>
> --
> Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
> Redakteur@Stacken \ S-161 43 BROMMA \ T: +46-8-26 52 47
> \ SWEDEN \ or +46-708-26 53 44
> Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
>
> Unsolicited commercial email is subject to an archival fee of $400.
> See <http://www.stacken.kth.se/~levitte/mail/> for more info.
> ______________________________________________________________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
