[openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread

[Paul Dale]

Nico,

Thanks for the clarification.  I was making an assumption that following the existing locking model, which did seem over complicated, was desirable.  Now that that is shot down, things can be much simpler.

It would make more sense to have a structure containing the reference counter and (optionally?) a lock to use for that counter.
With atomics, the lock isn't there or at least isn't used.  Without them, it is.  This is because, I somewhat suspect having a fall back global lock for all atomic operations would be worse than the current situation were at least a few different locks are used.

There is also the possibility of only using the per reference counter lock and not using atomic operations at all -- this would reduce the contention a lot and might not hurt performance much.  It would be easy to benchmark an uncontested lock/add/unlock versus atomic add on the target platforms to see the difference.


Thanks against for the insights,

Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia
On Wed, 9 Dec 2015 03:27:51 AM Nico Williams wrote:
> On Wed, Dec 09, 2015 at 02:33:46AM -0600, Nico Williams wrote:
> > No more installing callbacks to get locking and atomics.
> 
> I should explain why.
> 
> First, lock callbacks are a serious detriment to usability.
> 
> Second, they are an admission that OpenSSL is incomplete.
> 
> Third, if we have lock callbacks to install, then we have the risk of
> racing (by multiple libraries using OpenSSL) to install them.  Unless
> there's a single function to install *all* such callbacks, then there's
> no way to install callbacks atomically.  But every once in a while we'll
> need to add an Nth callback, thus breaking the ABI or atomicity.
> 
> So, no, no lock callbacks.  OpenSSL should work thread-safely out of the
> box like other libraries.  That means that the default configuration
> should be to use pthreads on *nix, for example.  We'll need an atomics
> library (e.g., OpenPA, or something new) with safe and sane -if not very
> performant- defaults that use global locks for platform/compiler
> combinations where there's no built-in atomics intrinsics or system
> library.  It should be possible to have a no-threads configuration where
> the locks and atomics are non-concurrent-safe implementations.
> 
> Nico
> --