RFR: 8186166: Generalize Atomic::cmpxchg with templates

[Kim Barrett]

> On Aug 14, 2017, at 10:28 AM, Roman Kennke <rkennke at redhat.com> wrote:
> 
> I still don't understand why we want to allow for different types for
> the new and expected values and the memory location (T, D and U). We
> haven't allowed for this before, why are we doing it now?

Different types are only permitted in the pointer value case,
e.g. cmpxchg(T*, D* volatile*, U*).

The compare_value type is permitted to differ from the destination's
value type only in cv-qualifiers.  Consider a member variable "var" of
type int*.

  const int* old_value = var;
  ... compute new_value ...
  cmpxchg(new_value, &var, old_value);

It is perfectly reasonable and appropriate to const-qualify
old_value's type in that way.  But that would require a source level
cast if cmpxchg required an exact type match for *dest and
compare_value.

We permit the exchange_value type to be less cv-qualified than the
*dest type.  We also permit derived to base conversions.  Both of
those are natural and type-safe, and may eliminate the need for some
source level casts.

> We haven't allowed for this before, why are we doing it now?

Because of the complete type-discarding done by cmpxchg_ptr, I suggest
we have no clue what our current code might or might not be doing.