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

[Nico Williams]

On Thu, Dec 10, 2015 at 07:06:15AM +1000, Paul Dale wrote:
> 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.

Exactly :)

Sorry if I was a bit brusque.  Since inertia is strong, I figured I
needed to make a forceful argument.  However, it seems it was easy to
get consensus after all.

> It would make more sense to have a structure containing the reference
> counter and (optionally?) a lock to use for that counter.

It'd work but it'd be a complication, since now every integer to be used
with atomic increment/decrement, or CAS, or whatever, now needs to be a
struct type with the integer as one field and the rest as opaque.  It'd
be much nicer to be able to use ints normally, though I would agree that
having a special type for atomics has the benefit that it is
self-describing.

It's perfectly fine to have a worst-case atomics implementation that
uses a global lock.  Yes, that would be slow, but we need some incentive
to add true atomics for each platform, and making it slow is the exact
right incentive.

So even if for documentation and type-safety reasons we wanted to wrap
ints in structs for ints meant to be used with atomics, I'd still want
the worst-case atomics implementation to be slow.

> 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.

That's a feature :)

Nico
--