> Guess I replied too quickly... I see why you thought I was spreading > misinformation. Of course I agree that every library could be modified > to use atomic instructions available on their CPU to synchronize. Its > just a lot of modifications to be made considering the vast amount of > code out there that uses OpenSSL. I'd like to see OpenSSL take care of > this (which is what I though you were arguing for too). > > -M
Actually, that wouldn't work. What if you're using a threading library that permits threads to run in different SMP domains? In that case, the atomic instructions would only synchronize between threads running in the same SMP domain. If one thread in one SMP domain attempts to set the thread synchronization primitives at the same time as a thread in another SMP domain does so, the CPU synchronization instructions would be insufficient. Such a platform might require a specific "synchronize memory view across domain" instructions when a lock was acquired or released, for example. I think you're missing the point that OpenSSL doesn't just support the typical platform-provided threading libraries. It supports *any* threading library the compiler can support. There is no guarantee that CPU-atomic operations are atomic in the same scope as any possible threading library the compiler can support requires. Trying to supply the library with atomic operations known safe for the required atomicity of the threading library in use creates a chicken and egg problem. You would need atomic operations to specify the atomic operations. Fundamentally, OpenSSL is not suitable for direct use a system library. It requires a wrapper to specify the threading model. (Whether or not this is a fault in OpenSSL or the people who decided to use it in a way it was not meant to be used is another question.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
