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