RFR: 8186838: Generalize Atomic::inc/dec with templates

[Kim Barrett]

> On Sep 5, 2017, at 10:55 AM, Erik Österlund <erik.osterlund at oracle.com> wrote:
> On 2017-09-05 02:38, Kim Barrett wrote:
>> […] Erik's proposal also uses IntegralContant for that purpose,
>> but (from a quick skim) I think got that part wrong, and that is a
>> source of additional complexity. Erik might want to re-read my handoff
>> email to him.  I don't know whether that approach would satisfy folks
>> though.
> 
> Unfortunately that approach did not work. It passed IntegralConstant as rvalue to operator(), which is illegal as IntegralConstant is an AllStatic class.

IntegralConstant is an AllStatic?  That’s just wrong!  And probably my fault too.

// A type n is a model of Integral Constant if it meets the following
// requirements:
//
[…]
// n::value_type const c = n() : c == n::value

>> I'm a little bit reluctant to just give up on per-platform
>> microoptimized inc/dec and simply transform those operations into
>> corresponding add operations.  Requiring an additional register and
>> it's initialization for some platforms seems like poor form.
> 
> If we insist on having these micro optimizations, I am not opposed to on selected x86 GCC platforms (were the risk for future ABI breakage is nearly zero) using GCC intrinsics for Atomic::add. If Atomic::inc/dec simply calls Atomic::add, then those GCC intrinsics will be able to micro optimize as you desire to the optimal lock add encoding.

I think I’d be okay with that too.