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

[Former user]

Originally reported on Google Code with ID 35 ``` 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.

```

Reported by `gary.funck` on 2012-05-22 04:58:11

[Former user]

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

Reported by `[e-mail]` on 2012-05-23 20:20:07

[Former user]

``` 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. ```

Reported by `[e-mail]` on 2012-07-02 21:48:17

[Former user]

``` 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. ```

Reported by `[e-mail]` on 2012-07-02 21:52:47

[Former user]

``` 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). ```

Reported by `[e-mail]` on 2012-07-02 22:14:55 - Labels added: Milestone-Spec-1.4