Re: bit fields && data tearing

Peter Hurley
2014-09-05T02:47:24Z

Hi James,

On 09/04/2014 10:11 PM, James Bottomley wrote:
> On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
>> +And there are anti-guarantees:
>> +
>> + (*) These guarantees do not apply to bitfields, because compilers often
>> + generate code to modify these using non-atomic read-modify-write
>> + sequences. Do not attempt to use bitfields to synchronize parallel
>> + algorithms.
>> +
>> + (*) Even in cases where bitfields are protected by locks, all fields
>> + in a given bitfield must be protected by one lock. If two fields
>> + in a given bitfield are protected by different locks, the compiler's
>> + non-atomic read-modify-write sequences can cause an update to one
>> + field to corrupt the value of an adjacent field.
>> +
>> + (*) These guarantees apply only to properly aligned and sized scalar
>> + variables. "Properly sized" currently means "int" and "long",
>> + because some CPU families do not support loads and stores of
>> + other sizes. ("Some CPU families" is currently believed to
>> + be only Alpha 21064. If this is actually the case, a different
>> + non-guarantee is likely to be formulated.)
>
> This is a bit unclear. Presumably you're talking about definiteness of
> the outcome (as in what's seen after multiple stores to the same
> variable).

No, the last conditions refers to adjacent byte stores from different
cpu contexts (either interrupt or SMP).

> The guarantees are only for natural width on Parisc as well,
> so you would get a mess if you did byte stores to adjacent memory
> locations.

For a simple test like:

struct x {
long a;
char b;
char c;
char d;
char e;
};

void store_bc(struct x *p) {
p->b = 1;
p->c = 2;
}

on parisc, gcc generates separate byte stores

void store_bc(struct x *p) {
0: 34 1c 00 02 ldi 1,ret0
4: 0f 5c 12 08 stb ret0,4(r26)
8: 34 1c 00 04 ldi 2,ret0
c: e8 40 c0 00 bv r0(rp)
10: 0f 5c 12 0a stb ret0,5(r26)

which appears to confirm that on parisc adjacent byte data
is safe from corruption by concurrent cpu updates; that is,

CPU 0 | CPU 1
|
p->b = 1 | p->c = 2
|

will result in p->b = 1 && p->c = 2 (assume both values
were 0 before the call to store_bc()).

Regards,
Peter Hurley