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 -- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
