On Thu, 2012-04-12 at 08:21 -0400, Andrew MacLeod wrote: > On 04/11/2012 06:38 PM, Torvald Riegel wrote: > > On Wed, 2012-04-11 at 15:06 +0200, Andi Kleen wrote: > >> > > Perhaps HLE_ACQUIRE / HLE_RELEASE should be something like HLE_START / > > HLE_END instead? Not particularly great names, but at least it avoids > > overloading ACQUIRE/RELEASE and thus should make it clearer that you > > still need to specify a memory order. > > > > > > Does it make any sense to simply predefine the possible valid > combinations with the HLE bit already set? it at least removes any > possible invalid combinations and forces the programmer to consciously > choose their memory model. > > ie, > __ATOMIC_HLE_XACQ_CONSUME > __ATOMIC_HLE_XACQ_ACQUIRE > __ATOMIC_HLE_XACQ_ACQ_REL > __ATOMIC_HLE_XACQ_SEQ_CST > > __ATOMIC_HLE_XREL_RELEASE > __ATOMIC_HLE_XREL_ACQ_REL > __ATOMIC_HLE_XREL_SEQ_CST > > or whatever happens to be valid... Doesn't really scale to adding more > new bits later, but perhaps that doesn't matter.
I would suggest that we keep the HLE acq/rel bits independent of the memory order bits. Both are independent on a conceptual level. And we should add documentation that tells programmers that memory orders need always be specified. This way, we: - keep it generic and don't add any arch-specific assumptions, - remain closer to a true extension of the C++11/C11 atomics instead of a more strongly coupled mix-up, - can still do arch-specific selection of memory orders (e.g., even just the memory orders are more fine-granular than you'd need for just x86), - can still do arch-specific warnings if some combinations really don't make sense, - keep the number of macros small as preferred by Jakub. Would that be an acceptable option for everyone? Andi, would proper documentation resolve your ease-of-use concerns?
