Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 15 Dec 2000 22:22:00 +0100 (CET)
From:      =?ISO-8859-1?Q?G=E9rard_Roudier?= <groudier@club-internet.fr>
To:        John Baldwin <jhb@FreeBSD.ORG>
Cc:        Bernd Walter <ticso@cicely5.cicely.de>, freebsd-alpha@FreeBSD.ORG
Subject:   RE: mb and wmb in atomic_
Message-ID:  <Pine.LNX.4.10.10012152205330.281-100000@linux.local>
In-Reply-To: <XFMail.001215113547.jhb@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Fri, 15 Dec 2000, John Baldwin wrote:

>=20
> On 15-Dec-00 Bernd Walter wrote:
> > Why are the mb and wmb operations needed in the atomic_ functions?
> > If I understood it correctly the locked operations are in synced
> > with others CPUs and there is no memory operation beside the variable
> > itself.
>=20
> They should probably only be used with the 'acq' and 'rel' variants.  Hmm=
, btw,
> it looks like I have the order of the barriers in the 'acq' and 'rel' var=
iants
> wrong.  The barriers should be on the inside, not the outside.  Anyone di=
sagree?

The mb() inside the atomic_ operations are obviously seriously
miscommented:

For example:

static __inline void atomic_set_32(volatile u_int32_t *p, u_int32_t v)
{
=09u_int32_t temp;

=09__asm __volatile (
=09=09"1:\tldl_l %0, %2\n\t"=09=09/* load old value */
=09=09"bis %0, %3, %0\n\t"=09=09/* calculate new value */
=09=09"stl_c %0, %1\n\t"=09=09/* attempt to store */
=09=09"beq %0, 2f\n\t"=09=09/* spin if failed */
=09=09"mb\n\t"=09=09=09/* drain to memory */
=09=09".section .text3,\"ax\"\n"=09/* improve branch prediction */
=09=09"2:\tbr 1b\n"=09=09=09/* try again */
=09=09".previous\n"
=09=09: "=3D&r" (temp), "=3Dm" (*p)
=09=09: "m" (*p), "r" (v)
=09=09: "memory");
}

There is obviously no relevance here in trying to drain something to
memory. Note that thinking about a mb() as something that drains to memory
is a serious mistake in my opinion. We want to order there, not to drain
anything anywhere.

However, the mb() above does have the effect of throwing away any read=20
that may have been prefetched by the CPU. If we need that here, we must
not remove the mb(), otherwise the mb() can be removed.

  G=E9rard.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10012152205330.281-100000>