Define accesses to UPC shared bit fields as atomic with respect to accesses to adjacent fields.

[GoogleCodeExporter]

This issue is responsive to item 52 on the open issues list.

52. For bit-fields of shared struct types, are there any guarantees regarding 
what  happens if two threads each write two different bit-fields within the 
same struct?  At least two implementations implement shared bit-field writes by 
fetching the entire struct (or at least a word), modifying the data, then 
writing it back.  This approach potentially throws away concurrent updates by 
other threads to conceptually distinct bit-fields.

The C99 specification does not define any constraints on the required behavior 
for bit-field accesses.  The GCC documentation offers the following guidance 
when the "volatile" qualifier is applied to bit-field accesses:
http://gcc.gnu.org/onlinedocs/gcc/Volatiles.html
"As bitfields are not individually addressable, volatile bitfields may be 
implicitly read when written to, or when adjacent bitfields are accessed. 
Bitfield operations may be optimized such that adjacent bitfields are only 
partially accessed, if they straddle a storage unit boundary. For these reasons 
it is unwise to use volatile bitfields to access hardware."

In an idealized implementation, accesses to bitfields within a UPC shared 
'struct' or 'union' would be atomic with respect to adjacent bit fields that 
reside within the same containing storage unit.  Although desirable in some 
situations, over-constraining the implementation in this way may impact 
performance when this level of atomicity is not needed.  Yet, if the principal 
of "least surprise" was followed here, atomic bitfield accesses would provide 
the most intuitive and predictable bitfield access behavior.

This proposal recommends that UPC shared bitfield accesses are defined as being 
atomic with respect to accesses to adjacent bitfields within the same 
(implementation-defined) containing storage unit.

Original issue reported on code.google.com by gary.funck on 22 May 2012 at 4:58

[GoogleCodeExporter]

If we are still seeking motivation for the masked-swap atomic operation for 
issue #7, then this issue of shared bit fields is it.

Original comment by [email protected] on 23 May 2012 at 8:20

[GoogleCodeExporter]

I see no progress has been made on this issue recently.

Do we have access to the C11 text?  I would be interested in seeing what it has 
to say with respect to threads and bit-field access (both with and without the 
_Atomic qualifier).  This is an area where we should avoid creating unnecessary 
conflicts.

Original comment by [email protected] on 2 Jul 2012 at 9:48

[GoogleCodeExporter]

In partial response to my own query, the "final committee draft" of C11 appears 
at
    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

Next I'll try to answer the rest of my own question.

Original comment by [email protected] on 2 Jul 2012 at 9:52

[GoogleCodeExporter]

Providing my own answer:

C11 makes _Atomic optional and leaves as implementation-defined whether or not 
_Atomic can be applied to bit-fields.  So, I believe that nothing (within 
reason) we might choose to specify for UPC would create a conflict in the 
future should we re-base UPC on C11.

I am assigning the 1.4 milestone to this because I doubt we can reach consensus 
quickly enough for 1.3 (unless we all want to ignore the question and go with 
NoChange).  As the reporter and owner, Gary is encouraged to override if he 
disagrees with me.

My thought is that the masked-swap atomic operation is a viable solution to the 
same problem as atomic access to bit-fields.  Since it is only used explicitly, 
it avoids adding overhead to the implementation when not required.  The 
significant downside is that a user must manually manage the bits within a word 
without the aid the compiler provides when one can name a bitfield (instead of 
specifying the containing object and a mask).

Original comment by [email protected] on 2 Jul 2012 at 10:14

• Added labels: Milestone-Spec-1.4