lkml.org 
[lkml]   [2014]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: bit fields && data tearing
    On Thu, Sep 04, 2014 at 03:16:03PM -0700, H. Peter Anvin wrote:
    > On 09/04/2014 12:42 PM, Peter Hurley wrote:
    > >
    > > Or we could give up on the Alpha.
    > >
    >
    > If Alpha is turning into Voyager (kept alive only as a museum piece, but
    > actively causing problems) then please let's kill it.

    Sorry for being slow to join this thread, but I propose the following
    patch. If we can remove support for all CPUs that to not support
    direct access to bytes and shorts (which I would very much like to
    see happen), I will remove the last non-guarantee.

    Thanx, Paul

    ------------------------------------------------------------------------

    documentation: Record limitations of bitfields and small variables

    This commit documents the fact that it is not safe to use bitfields
    as shared variables in synchronization algorithms.

    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

    diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
    index 87be0a8a78de..a28bfe4fd759 100644
    --- a/Documentation/memory-barriers.txt
    +++ b/Documentation/memory-barriers.txt
    @@ -269,6 +269,26 @@ And there are a number of things that _must_ or _must_not_ be assumed:
    STORE *(A + 4) = Y; STORE *A = X;
    STORE {*A, *(A + 4) } = {X, Y};

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

    =========================
    WHAT ARE MEMORY BARRIERS?


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