Date: Tue, 01 Oct 2019 13:53:05 -0600 From: Ian Lepore <ian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r352938 - head/sys/arm/include Message-ID: <d05424dfc32a7fd9bb004da280f9136e29cbe332.camel@freebsd.org> In-Reply-To: <20191001194932.GZ44691@kib.kiev.ua> References: <201910011939.x91Jd0tK010821@repo.freebsd.org> <20191001194932.GZ44691@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d05424dfc32a7fd9bb004da280f9136e29cbe332.camel>