Date: Wed, 30 Sep 2009 15:48:57 +0200 From: Attilio Rao <attilio@freebsd.org> To: Ivan Voras <ivoras@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r197643 - in head/sys: kern sys Message-ID: <3bbf2fe10909300648v51555353p864dd9682ecd884b@mail.gmail.com> In-Reply-To: <9bbcef730909300643k56e40be9xc8b8287dc2971ac3@mail.gmail.com> References: <200909301326.n8UDQVB1016396@svn.freebsd.org> <9bbcef730909300643k56e40be9xc8b8287dc2971ac3@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2009/9/30 Ivan Voras <ivoras@freebsd.org>: > 2009/9/30 Attilio Rao <attilio@freebsd.org>: >> Author: attilio >> Date: Wed Sep 30 13:26:31 2009 >> New Revision: 197643 >> URL: http://svn.freebsd.org/changeset/base/197643 >> >> Log: >> When releasing a read/shared lock we need to use a write memory barrier >> in order to avoid, on architectures which doesn't have strong ordered >> writes, CPU instructions reordering. > > Will this influence performance on those architecture that do? > No. In those architectures, memory barriers are crafted in the lighter possible way (aka often are the same operation as a 'simple' atomic, like the ia32 case). Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10909300648v51555353p864dd9682ecd884b>