On Thu, Oct 03, 2019 at 09:08:50AM -0400, Steven Rostedt wrote:
> On Thu, 03 Oct 2019 09:39:17 +0100
> David Howells <dhowe...@redhat.com> wrote:
>
> > paul...@kernel.org wrote:
> >
> > > +#define rcu_replace(rcu_ptr, ptr, c)
> > > \
> > > +({
> > > \
> > > + typeof(ptr) __tmp = rcu_dereference_protected((rcu_ptr), (c)); \
> > > + rcu_assign_pointer((rcu_ptr), (ptr)); \
> > > + __tmp; \
> > > +})
> >
> > Does it make sense to actually use xchg() if that's supported by the arch?
Historically, xchg() has been quite a bit slower than a pair of assignment
statements, in part due to the strong memory ordering guaranteed by
xchg(). Has that changed? If so, then, agreed, it might make sense to
use xchg().
> Hmm, is there really any arch that doesn't support xchg()? It would be
> very hard to do any kind of atomic operations without it.
>
> cmpxchg() is the one that I understand is optional by the arch.
To your point, even the old Sequent Symmetry platforms supported xchg()
back in the late 1980s and early 1990s, but only the later versions
(with 80486 and later) supported cmpxchg().
Thanx, Paul
