On Mon, 2010-06-28 at 07:06 -0700, David Schwartz wrote: > > 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.
Point taken. I suppose what I'm really after is a way out for libraries to be able to "do the right thing" with a minimum of code change. From what I've seen in the wider opensource world is that either libraries don't set the callbacks at all or set them without even checking to see if they're already set. The way OpenSSL currently works I don't see a simple solution. For vendors it could mean that OpenSSL is shipped with a default set of locking callbacks (e.g. Solaris could use phreads/solaris threads) but that is obviously not a generic solution and will not be suitable for all platforms/distributions. I seem to remember having this conversation a few months ago... :) -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
