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