lkml.org 
[lkml]   [2014]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: bit fields && data tearing
    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




    \
     
     \ /
      Last update: 2014-09-05 05:21    [W:4.699 / U:0.032 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site