Geoffrey Thorpe <ge...@geoffthorpe.com>: So I'm going to propose that we initially put this patch into the > development head only, and defer a decision on whether to cherry-pick it > into stable branches until that testing is in place. >
Sure, sounds right. (Will you go ahead and handle the patch?) I certainly don't want us to replace the mutex-using code with something > that uses mutex *or* rwlock depending on whether OPENSSL_PTHREADS_SUCK is > defined or not. > > BTW, I mention this because NPTL headers apparently cage the rwlock > definitions in some #ifdef-ery that I think we want to avoid in the > mutex->rwlock changes in openssl. Rather than grappling with the > will-some-platform-fail-in-some-subtle-way issues, I prefer that we rely on > the short-term arrival of platform coverage/testing to detect the issue if > there is one to cater for. > OK. For future work, a lock-free approach (using thread-local storage?) >> certainly might make sense, but switching to read-write locks in the >> default callbacks should be a tiny change with significant benefits to >> multithreaded applications. >> > > Yeah, but a couple of things come to mind. > > (1) rwlocks (under optimised conditions anyway) seem to be essentially > "lock free" in the fast-path case anyway, ie. for the > read-lock/no-contention case, due to futex magic. That means no > context-switch (to the kernel or otherwise) in that by-far-the-most-common > case. So I think a change to rwlocks is likely to eliminate the observable > syscall and contention overheads anyway. > Yes, that's what I'm thinking too. However, for those cases that actually do use the write lock (and remember that it's not *only* about CRYPTO_ERR, so merely avoiding errors doesn't resolve the issue :-) ), the current array of global locks is certainly generally not ideal. Bodo
