svn commit: r236456 - in head/sys: amd64/include i386/include

John Baldwin jhb at freebsd.org
Mon Jun 4 17:50:12 UTC 2012


On Monday, June 04, 2012 10:27:49 am Konstantin Belousov wrote:
> On Mon, Jun 04, 2012 at 02:58:57PM +0100, Attilio Rao wrote:
> > 2012/6/4 Konstantin Belousov <kostikbel at gmail.com>:
> > > On Mon, Jun 04, 2012 at 12:00:27PM +0200, Tijl Coosemans wrote:
> > >> On 02-06-2012 20:10, Konstantin Belousov wrote:
> > >> > Author: kib
> > >> > Date: Sat Jun  2 18:10:16 2012
> > >> > New Revision: 236456
> > >> > URL: http://svn.freebsd.org/changeset/base/236456
> > >> >
> > >> > Log:
> > >> >   Use plain store for atomic_store_rel on x86, instead of implicitly
> > >> >   locked xchg instruction.  IA32 memory model guarantees that store has
> > >> >   release semantic, since stores cannot pass loads or stores.
> > >>
> > >> They can pass non-temporal stores can't they?
> > > Sure. But (our) barriers only work for WB memory accesses, in respect to other
> > > WB memory accesses.
> > >
> > > The atomic(9) contains not quite explicit mention of the requirement,
> > > for ia32 and more direct notion for ia64. It could probably be reworded to
> > > mention memory access type explicitely for ia32 too.
> > 
> > I don't think this is right.
> > What if I want to use NTI in a block of code locked? What if I want to
> > use CLFLUSH? I simply cannot do that now because of the reordering
> > requirement.
> Assuming that NTI means "Non Temporal Instruction", Intel explicit
> requirement is to use fence barrier if order shall be ensured. This,
> as well as CLFLUSH use, is somewhat commonly documented. More, CLFLUSH
> is documented by Intel to _not_ serialize with any other fencing or
> serialization instruction, except MFENCE. So xchg-based _store_rel is
> not different from mov-based _store_rel for CLFLUSH and non-temporal
> ops.

I agree, having recently worked with movnt at work, if you are going to
use these instructions, you will need to use your own explicit fences.

No code should depend on implict barriers in locking primitives for working
with movnt.

-- 
John Baldwin


More information about the svn-src-all mailing list