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

[Paul Dale]

The "have-atomics" is intended to test if the callback was installed by the user.  If we're using an atomic library or compiler support, then it isn't required since we know we've got them.

Likewise, the lock argument isn't required if atomics are used everywhere.  However, some code will need fixing since there are places that adjust reference counters directly using arithmetic operators (while holding the appropriate lock).  These will have to be changed to atomics and the locked sections of code checked to see that that doesn't introduce other problems.

All possible of course.


Pauli


On Tue, 8 Dec 2015 10:01:20 PM Nico Williams wrote:
> On Wed, Dec 09, 2015 at 09:27:16AM +1000, Paul Dale wrote:
> > It will be possible to support atomics in such a way that there is no
> > performance penalty for machines without them or for single threaded
> > operation.  My sketcy design is along the lines of adding a new API
> > CRYPTO_add_atomic that takes the same arguments as CRYPTO_add (i.e.
> > reference to counter, value to add and lock to use):
> > 
> > CRYPTO_add_atomic(int *addr, int amount, int lock)
> >     if have-atomics then
> >         atomic_add(addr, amount)
> >     else if (lock == have-lock-already)
> >         *addr += amount
> >     else
> >         CRYPTO_add(addr, amount, lock)
> 
> "have-atomics" must be known at compile time.
> 
> "lock" should not be needed because we should always have atomics, even
> when we don't have true atomics: just use a global lock in a stub
> implementation of atomic_add() and such.  KISS.  Besides, this will add
> pressure to add true atomics wherever they are truly needed.
> 
> Nico
> -- 

-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia