lkml.org 
[lkml]   [2018]   [Jul]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCHv2 06/11] atomics/treewide: rework ordering barriers
    On Wed, Jul 04, 2018 at 04:06:46PM +0100, Will Deacon wrote:
    > On Mon, Jun 25, 2018 at 11:59:47AM +0100, Mark Rutland wrote:
    > > Currently architectures can override __atomic_op_*() to define the barriers
    > > used before/after a relaxed atomic when used to build acquire/release/fence
    > > variants.
    > >
    > > This has the unfortunate property of requiring the architecture to define the
    > > full wrapper for the atomics, rather than just the barriers they care about,
    > > and gets in the way of generating atomics which can be easily read.
    > >
    > > Instead, this patch has architectures define an optional set of barriers,
    > > __atomic_mb_{before,after}_{acquire,release,fence}(), which <linux/atomic.h>
    > > uses to build the wrappers.
    >
    > Looks like you've renamed these in the patch but not updated the commit
    > message.

    Yup; Peter also pointed that out. In my branch this now looks like:

    ----
    Instead, this patch has architectures define an optional set of barriers:

    * __atomic_acquire_fence()
    * __atomic_release_fence()
    * __atomic_pre_fence()
    * __atomic_post_fence()

    ... which <linux/atomic.h> uses to build the wrappers.
    ----

    ... which is hopefully more legible, too!

    > Also, to add to the bikeshedding, would it worth adding "rmw" in there
    > somewhere, e.g. __atomic_post_rmw_fence, since I assume these only
    > apply to value-returning stuff?

    I don't have any opinion there, but I'm also not sure I've parsed your
    rationale correctly. I guess a !RMW full-fence op doesn't make sense? Or
    that's something we want to avoid in the API?

    AFAICT, we only use __atomic_{pre,post}_fence() for RMW ops today.

    Thanks,
    Mark.

    \
     
     \ /
      Last update: 2018-07-04 17:57    [W:5.048 / U:0.000 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site