svn commit: r352938 - head/sys/arm/include

[Ian Lepore]

On Tue, 2019-10-01 at 22:49 +0300, Konstantin Belousov wrote:
> On Tue, Oct 01, 2019 at 07:39:00PM +0000, Ian Lepore wrote:
> > Author: ian
> > Date: Tue Oct  1 19:39:00 2019
> > New Revision: 352938
> > URL: https://svnweb.freebsd.org/changeset/base/352938
> > 
> > Log:
> >   Add 8 and 16 bit versions of atomic_cmpset and atomic_fcmpset for arm.
> >   
> >   This adds 8 and 16 bit versions of the cmpset and fcmpset functions. Macros
> >   are used to generate all the flavors from the same set of instructions; the
> >   macro expansion handles the couple minor differences between each size
> >   variation (generating ldrexb/ldrexh/ldrex for 8/16/32, etc).
> >   
> >   In addition to handling new sizes, the instruction sequences used for cmpset
> >   and fcmpset are rewritten to be a bit shorter/faster, and the new sequence
> >   will not return false when *dst==*old but the store-exclusive fails because
> >   of concurrent writers. Instead, it just loops like ldrex/strex sequences
> >   normally do until it gets a non-conflicted store. The manpage allows LL/SC
> >   architectures to bogusly return false, but there's no reason to actually do
> >   so, at least on arm.
> 
> The reason is to avoid nested loops.  The outer control for retry was the
> initial design decision for fcmpset() comparing to cmpset().  casueword()
> also started following this approach after the fixes for ll/sc looping
> after the external control.

If the implementation is forbidden from looping, then the manpage
should say so.  What I commited meets the requirements currently stated
in the manpage.  Until somebody explains to me why it is somehow
harmful to return the RIGHT information at a cost of either 0 or 1
extra cpu cycle, it's staying the way it is.

-- Ian