Re: The cost of pthread-mutexes or corresponding...

[Richard Levitte - VMS Whacker]

From: Rich Salz <[EMAIL PROTECTED]>

rsalz> What is the problem you are trying to solve?  Who has asked for it?

The problems is operations on one object locking out operations on
separate objects of the same type (thus making the locking needless in
that sense).  I have asked for it quite some time ago, see
http://www.opeenssl.org/thoughts/MT-mutexes.txt

rsalz> I think it is a fool's errand to try to make it possible to
rsalz> "share" every data structure across threads.

Noone has said "every", but some have asked for "some".  I've
mentioned X509 structure, someone else has mentioned RSA structures,
and SSL structures have been mentioned several times...

rsalz> You can't get it exactly right, you need higher-level
rsalz> information that is in the application, not at the OpenSSL
rsalz> level.  Suppose you add a lock to LHASH -- what happens for
rsalz> lh_doall -- do you unlock when the function is called -- you
rsalz> can't, because someone might delete an element you're iterating
rsalz> over -- or do you keep it locked throughout the function -- so
rsalz> the function better not try to retrieve anything else from the
rsalz> hash?

Actually. LHASH could be the perfect example, because LHASHes are
shared across threads, see for example the object database.  However,
locking is solved by doing it some level above, for the structure that
contains an LHASH...

rsalz> And that's just one example.  But it indicates why (a)
rsalz> recursive locks can be needed; (b) why a simple lock, versus
rsalz> read/write, isn't enough; (c) shows the dangers of sharing
rsalz> objects across threads.

(b) Actually, we have r and w locks, but it doesn't stop the
    application from implementing them as w locks all over the
    place...

rsalz> I believe other matters -- the build/configure environment --
rsalz> are more pressing.

Uhmm, that would require people to think in a highly structure way and
at the same time.  Sorry, I don't believe that will ever happen :-).

However, what we do with everything that is called upon is a different
matter.  So right now, this matter is voiced.  What we do with it and
when is a different matter...

-- 
Richard Levitte   \ Spannvägen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

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]