Date: Wed, 13 Dec 2006 12:26:46 -0500 From: John Baldwin <jhb@freebsd.org> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-stable@freebsd.org, Suleiman Souhlal <ssouhlal@freebsd.org>, Attilio Rao <attilio@freebsd.org>, freebsd-current@freebsd.org, bde@freebsd.org, Kostik Belousov <kostikbel@gmail.com>, tegge@freebsd.org Subject: Re: kqueue LOR Message-ID: <200612131226.48087.jhb@freebsd.org> In-Reply-To: <20061213133411.S1136@delplex.bde.org> References: <456950AF.3090308@sh.cvut.cz> <200612121412.13551.jhb@freebsd.org> <20061213133411.S1136@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 12 December 2006 21:48, Bruce Evans wrote:
> > Memory barriers just specify ordering, they don't ensure a cache flush so
> > another CPU reads up to date values. You can use memory barriers in
> > conjunction with atomic operations on a variable to ensure that you can
> > safely read other variables (which is what locks do). For example, in
this
>
> I thought that the acquire/release variants of atomic ops guarantee
> this. They seem to be documented to do this, while mutexes don't seem
> to be documented to do this. The MI (?) implementation of mutexes
> depends on atomic_cmpset_{acq,rel}_ptr() doing this.
The acq/rel just specify ordering. As Attilio mentioned, we assume that the
atomic_cmpset() that sets the contested flag will fail while racing with
another CPU (even if the CPU can't see the new value, as long as it fails and
keeps spinning mutexes will still work). The 'rel' barrier on CPU A when
releasing a lock forces all the other writes to be posted (and eventually
become "visible") to other CPUs before the write that releases the lock.
The 'acq' barrier on CPU B when acquiring the lock forces the CPU to not
reorder any reads before it acquires the lock, so this makes you not read any
data until you have the lock. Thus, once CPU B has waited long enough
to "see" the write from A to release the lock, we know that 1) it can
also "see" all the other writes from that CPU that the lock protected, and 2)
B hasn't tried to read any of them yet so it shouldn't have any stale values
in registers. None of this requires the OS to do a cache flush. (If you
have an SMP system where the cache can still hold stale values after another
CPU updates values in memory where it is "visible" to the CPU acquiring the
lock, then _acq might need to flush the cache, but that would be a property
of that architecture. However, even that would not require cache flushes so
long as the stale values were evicted from the cache such that they honor the
memory barrier and you don't see the new value of the lock until you see the
new values of the earlier data.)
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612131226.48087.jhb>