On Tue, Jul 14, 2015 at 11:58:37AM +0100, Peter Zijlstra wrote:
> On Tue, Jul 14, 2015 at 11:32:20AM +0100, Will Deacon wrote:
> > On Tue, Jul 14, 2015 at 11:25:11AM +0100, Peter Zijlstra wrote:
> > > Could we not define _{acquire,release} in terms of _relaxed and
> > > smp_mb__{after,before}_atomic() ?
> > 
> > I actually started out with that, but it penalises architectures that
> > don't have _relaxed implementations of some routines.
> 
> #ifndef atomic_add_return_relaxed
> 
> #define atomic_add_return_relaxed     atomic_add_return
> /*
>  * If one cannot define a more relaxed version,
>  * acquire/release are out the window too.
>  */
> #define  atomic_add_return_acquire    atomic_add_return
> #define  atomic_add_return_release    atomic_add_return
> 
> #else /* relaxed */
> 
> #ifndef atomic_add_return_acquire
> #define  atomic_add_return_acquire(args...)   \
> do {                                          \
>       atomic_add_return_relaxed(args);        \
>       smp_mb__after_atomic();                 \
> } while (0)
> #endif
> 
> #ifndef atomic_add_return_release
> #define  atomic_add_return_release(args...)   \
> do {                                          \
>       smp_mb__before_atomic();                \
>       atomic_add_return_relaxed(args);        \
> } while (0)
> #endif
> 
> #endif /* relaxed */

If a picture is worth a thousand words, a patch is worth at least a thousand
pictures.

I'll add this for v2.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to