As has been mentioned before, I've given some thought to having
thread-locks with a higher granularity than we have today. As it is
now, the locking is done at type level (class level for the OO
fanatics). This means that if some thread locks CRYPTO_LOCK_RSA, all
operations that need to lock that lock will hang until the first one
is done. This degrades the potential performance quite a lot, I'd
think.
After having given some OpenSSL-specific locking mechanism a bit of
thought, I've concluded that it's not possible to make something that
is portable and as efficient as whatever is used in the operating
system. This means that we would basically use the dynamic locks that
I implemented some time ago or something close to it.
Using dynamic locks would create fragmentation of the heap, but there
are solutions to that, to some level of intricacy. However, there's
something else that disturbs me a bit, and it's the thought that locks
may be a limited resource and can't therefore be littered all over the
heap without some performance hit or something else.
What I'd like to know is if the following structures are basically
just a memory blob with some bits that are fiddled with, or if it's a
handle to some bulkier resource. It's probably OK to create, say,
10000 of the former without ay problem, the latter would create
problems in those quantities:
pthread mutexes
Windows critical sections
others?
--
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]
The cost of pthread-mutexes or corresponding...
Richard Levitte - VMS Whacker Thu, 14 Dec 2000 15:16:22 -0800
- Re: The cost of pthread-mutexes or correspon... Richard Levitte - VMS Whacker
- Re: The cost of pthread-mutexes or corr... Rich Salz
- Re: The cost of pthread-mutexes or corr... Richard Levitte - VMS Whacker
- Re: The cost of pthread-mutexes or corr... Arne Ansper
- Re: The cost of pthread-mutexes or corr... Rich Salz
- Re: The cost of pthread-mutexes or ... Bodo Moeller
- Re: The cost of pthread-mutexes or corr... Sean Walton
- Re: The cost of pthread-mutexes or ... Richard Levitte - VMS Whacker
- Re: The cost of pthread-mutexes or corr... Sean Walton
- Re: The cost of pthread-mutexes or corr... Richard Levitte - VMS Whacker
- Re: The cost of pthread-mutexes or corr... Rich Salz
