Paul Sheer wrote:
In my opinion what you are doing is going to result in some subtle bug that is going to be impossible to track down if there is even a single location where two threads can step on each other's toes.Locking with no contention is not "pretty expensive", it's darnnear free.Oh? If this is true it changes things somewhat. But I must say that I believe that no-one has ever used OpenSSL with 10'000 concurrent SSL objects. So I'm not going to take the chance that there will be any performance degradation. I'd rather have the GUARANTEE that there is no lock contention AT ALL.
Locks are placed into the code when the developer of the code believes it is not safe to perform an operation in a multi-threaded environment without the guarantee that no other thread can be accessing or manipulating the same data. If your application is designed correctly and there is in fact no contention between the threads, then the cost of obtaining and releasing locks will be inconsequential.
You can do what you will but as someone who has years of experience tracking down bugs in live systems caused by races between threads that were not prevented by locks, I think you are being foolish. It is not worth the cost of a production system going down or valuable data being lost or corrupted.
Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
