From owner-freebsd-current  Sun Jul 11 16:14:36 1999
Delivered-To: freebsd-current@freebsd.org
Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10])
	by hub.freebsd.org (Postfix) with ESMTP id BD97714FC1
	for <freebsd-current@FreeBSD.ORG>; Sun, 11 Jul 1999 16:14:32 -0700 (PDT)
	(envelope-from jeremyp@gsmx07.alcatel.com.au)
Received: by border.alcanet.com.au id <40350>; Mon, 12 Jul 1999 08:56:24 +1000
Date: Mon, 12 Jul 1999 09:14:17 +1000
From: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>
Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm")
In-reply-to: <199907112249.PAA16398@ducky.net>
To: mike@ducky.net
Cc: freebsd-current@FreeBSD.ORG
Message-Id: <99Jul12.085624est.40350@border.alcanet.com.au>
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Mike Haertel <mike@ducky.net> wrote:
>Um.  FYI on x86, even if the compiler generates the RMW
>form "addl $1, foo", it's not atomic.  If you want it to
>be atomic you have to precede the opcode with a LOCK
>prefix 0xF0.

I'd noticed that point as well.  The top of sys/i386/include/atomic.h
_does_ make is clear that they aren't SMP safe:

/*
 * Various simple arithmetic on memory which is atomic in the presence
 * of interrupts.
 *
 * Note: these versions are not SMP safe.
 */

That said, it should be fairly simple to change Matt's new in-line
assembler versions to insert LOCK prefixes when building an SMP
kernel.  (Although I don't know that this is necessary yet, given
the `Big Giant Lock').

There remains the problem of locating all the operations in the kernel
that _should_ be atomic but aren't marked as such.  Doug Rabson and
the rest of the Alpha porting crew will have found a lot of these, but
locating race conditions by waiting for them to occur is not the best
solution.

Peter


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