Date: Mon, 23 Apr 2012 15:07:20 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Fengwei yin <yfw.bsd@gmail.com> Cc: freebsd-threads@freebsd.org, jack.ren@intel.com Subject: Re: About the memory barrier in BSD libc Message-ID: <20120423120720.GS2358@deviant.kiev.zoral.com.ua> In-Reply-To: <CAPHpMumWu_aaZ4Sj5Athro6441Y%2B3_phbD2jxkKE-CdBf-Fd8g@mail.gmail.com> References: <CAPHpMu=DOGQ=TuFeYH7bH8hVwteT4Q3k67-mvoOFob6P3Y506w@mail.gmail.com> <20120423084120.GD76983@zxy.spb.ru> <CAPHpMu=kCwhf1RV_sYBDWDPL8368YTMLXge4L_g_F4AkTX1H5g@mail.gmail.com> <20120423094043.GS32749@zxy.spb.ru> <CAPHpMukLUeetSKpH2oiKJQ3ML_PFHEi6a0hK3_Ery=LX1YEd3g@mail.gmail.com> <20120423113838.GT32749@zxy.spb.ru> <CAPHpMumWu_aaZ4Sj5Athro6441Y%2B3_phbD2jxkKE-CdBf-Fd8g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--o4p1YyT9pdUjNGfy
Content-Type: text/plain; charset=koi8-r
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Apr 23, 2012 at 07:44:34PM +0800, Fengwei yin wrote:
> On Mon, Apr 23, 2012 at 7:38 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> wrot=
e:
> > On Mon, Apr 23, 2012 at 07:26:54PM +0800, Fengwei yin wrote:
> >
> >> On Mon, Apr 23, 2012 at 5:40 PM, Slawa Olhovchenkov <slw@zxy.spb.ru> w=
rote:
> >> > On Mon, Apr 23, 2012 at 05:32:24PM +0800, Fengwei yin wrote:
> >> >
> >> >> On Mon, Apr 23, 2012 at 4:41 PM, Slawa Olhovchenkov <slw@zxy.spb.ru=
> wrote:
> >> >> > On Mon, Apr 23, 2012 at 02:56:03PM +0800, Fengwei yin wrote:
> >> >> >
> >> >> >> Hi list,
> >> >> >> If this is not correct question on the list, please let me know =
and
> >> >> >> sorry for noise.
> >> >> >>
> >> >> >> I have a question regarding the BSD libc for SMP arch. I didn't =
see
> >> >> >> memory barrier used in libc.
> >> >> >> How can we make sure it's safe on SMP arch?
> >> >> >
> >> >> > /usr/include/machine/atomic.h:
> >> >> >
> >> >> > #define mb() =9A =9A__asm __volatile("lock; addl $0,(%%esp)" : : =
: "memory")
> >> >> > #define wmb() =9A __asm __volatile("lock; addl $0,(%%esp)" : : : =
"memory")
> >> >> > #define rmb() =9A __asm __volatile("lock; addl $0,(%%esp)" : : : =
"memory")
> >> >> >
> >> >>
> >> >> Thanks for the information. But it looks no body use it in libc.
> >> >
> >> > I think no body in libc need memory barrier: libc don't work with
> >> > peripheral, for atomic opertions used different macros.
> >>
> >> If we check the usage of __sinit(), it is a typical singleton pattern =
which
> >> needs memory barrier to make sure no potential SMP issue.
> >>
> >> Or did I miss something here?
> >
> > What architecture with cache incoherency and FreeBSD support?
>=20
> I suppose it's not related with cache inchoherency (I could be wrong).
> It's related
> with reorder of instruction by CPU.
>=20
> Here is the link talking about why need memory barrier for singleton:
> http://www.oaklib.org/docs/oak/singleton.html
>=20
> x86 has strict memory model and may not suffer this kind of issue. But
> ARM need to
> take care of it IMHO.
Please note that __sinit is idempotent, so double-initialization is not
an issue there. The only possible problematic case would be other thread
executing exit and not noticing non-NULL value for __cleanup while current
thread just set it.
I am not sure how much real this race is. Each call to _sinit() is immediat=
ely
followed by a lock acquire, typically FLOCKFILE(), which enforces full barr=
ier
semantic due to pthread_mutex_lock call. The exit() performs __cxa_finalize=
()
call before checking __cleanup value, and __cxa_finalize() itself locks
atexit_mutex. So the race is tiny and probably possible only for somewhat
buggy applications which perform exit() while there are stdio operations
in progress.
Also note that some functions assign to __cleanup unconditionally.
Do you see any real issue due to non-synchronized access to __cleanup ?
--o4p1YyT9pdUjNGfy
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)
iEYEARECAAYFAk+VRfgACgkQC3+MBN1Mb4gD6QCbBIrbxxcIBGlcoq5YjXrK7Qtk
QYUAoNz43XBHSKfIFabK1+WaStPB5ddV
=wpqq
-----END PGP SIGNATURE-----
--o4p1YyT9pdUjNGfy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120423120720.GS2358>