Date: Tue, 18 Sep 2012 13:22:37 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Dimitry Andric <dim@freebsd.org> Cc: Davide Italiano <davide@freebsd.org>, src-committers@freebsd.org, John Baldwin <jhb@freebsd.org>, Jeff Roberson <jeff@freebsd.org>, attilio@freebsd.org, svn-src-projects@freebsd.org Subject: Re: svn commit: r238907 - projects/calloutng/sys/kern Message-ID: <20120918102237.GA37286@deviant.kiev.zoral.com.ua> In-Reply-To: <505849DB.3090704@FreeBSD.org> References: <201207301350.q6UDobCI099069@svn.freebsd.org> <CAJ-FndBj8tpC_BJXs_RH8sG2TBG8yA=Lxu3-GTVT9Ap_zOCuVQ@mail.gmail.com> <CAJ-FndDnO7wjnWPV0tTu%2BUGHjsxa3YDarMxmyei3ZmjLAFvRkQ@mail.gmail.com> <201207301732.33474.jhb@freebsd.org> <CAJ-FndD5EO12xsWOAe6u0EvX00q33wxO4OivnGjzj0=T2Oe8uA@mail.gmail.com> <CAJ-FndCRg0UCThFkatp=tw7rUWWCvhsApLE=iztLpxpGBC1F9w@mail.gmail.com> <505849DB.3090704@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
On Tue, Sep 18, 2012 at 12:15:55PM +0200, Dimitry Andric wrote:
> On 2012-09-18 02:13, Attilio Rao wrote:
> > On Thu, Aug 2, 2012 at 9:56 PM, Attilio Rao <attilio@freebsd.org> wrote:
> >> On 7/30/12, John Baldwin <jhb@freebsd.org> wrote:
> ...
> >> While here, did you consider also:
> >> - Abstracting compiler_memory_barrier() into a MI, compiler dependent function?
> >
> > So what do you think about this patch? (Please double-check the GIT log).
> ...
>
> > diff --git a/sys/sys/cdefs.h b/sys/sys/cdefs.h
> > index 8224672..fc6a75f 100644
> > --- a/sys/sys/cdefs.h
> > +++ b/sys/sys/cdefs.h
> > @@ -114,6 +114,13 @@
> > #endif
> >
> > /*
> > + * Compiler memory barriers, specific to gcc and clang.
> > + */
> > +#if defined(__GNUC__)
> > +#define __compiler_membar() __asm __volatile(" " : : : "memory")
> > +#endif
> > +
> > +/*
> > * The __CONCAT macro is used to concatenate parts of symbol names, e.g.
> > * with "#define OLD(foo) __CONCAT(old,foo)", OLD(foo) produces oldfoo.
> > * The __CONCAT macro is a bit tricky to use if it must work in non-ANSI
>
> Please use gcc's __sync_synchronize() builtin[1] instead, which is
> specifically for this purpose. Clang also supports it.
>
> The builtin will emit actual memory barrier instructions, if the target
> architecture supports it, otherwise it will emit the same asm statement
> you show above. See contrib/gcc/builtins.c, around line 5584, function
> expand_builtin_synchronize().
We do not need CPU barriers there, which are already handled by the atomic
asms. It is only to prevent compiler from exploiting the reorder.
>
> -Dimitry
>
> [1]: <http://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html#index-g_t_005f_005fsync_005fsynchronize-2843>;
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAlBYS20ACgkQC3+MBN1Mb4iHmACbBBAd6zNW3q8hljmDuh3LJ5dk
MHoAn0pEpqLcpmF8/Z5eUkMuvWGnbvbP
=DOak
-----END PGP SIGNATURE-----
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120918102237.GA37286>