Date: Sun, 4 Aug 2013 00:07:00 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: svn-src-projects@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r253908 - projects/atomic64/sys/i386/include Message-ID: <20130803233103.U1054@besplex.bde.org> In-Reply-To: <201308030055.r730tJxV071312@svn.freebsd.org> References: <201308030055.r730tJxV071312@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 3 Aug 2013, Jung-uk Kim wrote:
> Log:
> Remove two more "memory" from clobber list missed in the previous commit.
Isn't it always needed for acquire/release semantics? Or at least one of
those?
I previously asked (in private mail?) whether just declaring asms volatile
gives sufficient protection. It prevents the compiler reordering code.
Thus the compiler must not move loads or stores across the asm. This seems
to affect only stores:
foo = 1; /* must store before the asm */
bar = baz; /* can delay this */
__volatile __asm(""): /* no memory clobber */
use(bar); /* can use copy loaded before the asm
* or discard that copy, either by not
* loading it or making another copy,
* since the asm said that it didn't
* clober memory */
Stores need sort of the opposite of a memory clobber (to force all stores
to memory before the asm, in case the asm accesses memory not described
in the constraints). This is spelled __volatile and not put in the
clobber list.
Atomic loads and stores now use __compiler_membar(), which is a volatile
asm with a memory clobber on all arches. Atomic ops like add now use a
volatile asm without a memory clobber on x86, although they have acq/rel
variants. Old atomic readandclear didn't use a memory clobber. Old
atomic cmpset did use a memory clobber. Some of these must be wrong.
cmpset has the memory written to in a constraint, so it doesn't need
a memory clobber any more than readandclear except in very old versions
where it was missing the constraint.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130803233103.U1054>