Darryl Miles wrote: > David Schwartz wrote:
> > 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. > As I hinted in another post, the less common environments should be the > ones made to customize their OpenSSL implementation to suit their > platform. I would agree if OpenSSL just magically worked on these kinds of platforms and required something extra to work on common platforms. But OpenSSL is totally threading-model agnostic. It requires, on every platform, that you register the appropriate functions with it. It does not prefer unusual models and penalize common ones. > No one is advocating the removal of the ability to setup and > configure your own bespoke engineering solution to support threading on > your platform. By asking OpenSSL to implement specific types of atomic operations that work on some threading models but not others, that may be exactly what you wind up doing. > In order for an application to work in these rare use cases there must > already be some amount of kludge away from the more common model (how > many multi-threaded applications work out of the box on your cited > platform ?). OpenSSL can still work for them just like it does now. I can't see any reason any kludge is necessary. All that's needed is that you not make assumptions about the threading model. Lots of code makes no assumptions about the threading model's internal implementation, including code that uses only POSIX-compliant functions. > A question for you, are you stating an unmodified OpenSSL is being used > to your knowledge on the kind of platform you are suggesting ? Since > my > understanding of OpenSSL is that it will not work in a non-symmetric > memory system unmodified. I have no knowledge, but OpenSSL would work perfectly on such a platform. > OpenSSL's alloc/free must consistently allocate memory mapped at the > same virtual address space that is mapped and visible across every > thread that uses OpenSSL (maybe I have over generalized here). I'm > sure > such systems have provisions for mappings and arena based allocation. > This also means that the OpenSSL DLL shared data sections (.bss, .data > and .rodata) must also meet this requirement. OpenSSL's alloc/free must allocate memory from a single address space, but you can do that in non-SMP systems. As a hypothetical, imagine a 64-bit system where each SMP domain had its own 10GB address range reserved. Each thread allocates memory from its own range. (Of course, 'free' must accept a return of address space from and to any range.) Now, imagine further that a change made in one range was not visible in other ranges until you locked or unlocked a mutex. (And domains were permitted to cache data until a mutex operation occurred.) OpenSSL would support such a platform perfectly, assuming the mutex functions and memory allocation functions were appropriate. But atomic instructions would not work, as nothing would synchronize them access SMP domains. > This also means my proposal to use CPU-atomic operation will work fine, > since the synchronization point comes from memory allocated from .data > DLL section. This point has already been described in a previous post > of mine. It won't work. One thread will make a modification to the data section and then another thread will expect to be able to see that modification even though no operation synchronizes memory between the two threads. If the threads are in separate domains, you would need some mutex operation in each thread to make the changes visible. > Maybe you have misunderstood my intentions to be "I am seeking to > replace all threading ops with CPU-atomic instructions." LOL! NO I AM > NOT. I am merely proposing the use of a spinlock to protect the > threading model setup and query functions, to provide atomic > test-maybe-set. These functions are used infrequently and usually only > once by whatever subsystem is initializing at the time. The problem is that you have no way to know if these instructions are adequate for the threading model in use. Your change will work very well for platforms where it's adequate and terribly for platforms where it's not. Why not just do it the right way and adapt OpenSSL to the particular platform you plan to use it on? > > 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. > I understand your point and nothing being suggested hampers your > continued use of OpenSSL on these exotic platforms. I'm not taking > anything away, just making life easier for a cross-section of users on > common platforms. If there is some kind of consensus that OpenSSL should "just work" on some threading platforms and require special adaptation code on others, then so be it. Personally, I much prefer that it require the primitives be registered on all platforms, as it reduces the chances that future platform changes will cause working code to break. > > 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. > You just need ABI rules (which are already provided by your executable > file format). > > You really need to describe in detail how it becomes unsafe so you/I > can > point out where your/my thinking has gone wrong. What happens when programmers rely on the atomic operations to make the registration safe but you have a platform where the atomic operations are inadequate to do so? I don't see the utility of a 'safety' you can't rely on because people will start to rely on it and then their code will break. > And to repeat and clarify the nature of the problem again, "implicit > loading of OpenSSL DSOs, due to being dependent libraries of other > dynamically loaded objects". > The "superior executable program" doesn't use OpenSSL (directly) > itself, > but it dynamically loaded at runtime "another.so" which does need to > use > OpenSSL. But the "superior executable program" being modular also > loaded at runtime "yetanother.so" and this also implicitly loads > OpenSSL > since it also needs it directly. Whose fault was it again ? systemic > failure ? design failure ? I suppose the technical answer is that the fault is of the library authors who failed to coordinate their use of a process-level resource. But that doesn't really help, because there is no practical way they could have coordinated. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
