From owner-freebsd-current Mon Jul 12 2:14:34 1999 Delivered-To: freebsd-current@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 8B07214D47 for ; Mon, 12 Jul 1999 02:14:26 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 0837981; Mon, 12 Jul 1999 17:11:49 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Doug Rabson Cc: Peter Jeremy , mike@ducky.net, freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") In-reply-to: Your message of "Mon, 12 Jul 1999 09:00:59 +0100." Date: Mon, 12 Jul 1999 17:11:48 +0800 From: Peter Wemm Message-Id: <19990712091149.0837981@overcee.netplex.com.au> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Doug Rabson wrote: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > > Mike Haertel 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'). > > We don't need the lock prefix for the current SMP implementation. A lock > prefix would be needed in a multithreaded implementation but should not be > added unless the kernel is an SMP kernel otherwise UP performance would > suffer. I was under the impression that a locked instruction was essentially free at runtime, with the sole exception of being one byte larger. If there is any chance of this stuff getting exported to modules via inlines, it should support both as we don't need any more differences between SMP and non-SMP modules than we've already got. :-( Also, with the posted example, atomic_cmpex() is #ifndef I386_CPU - that means it won't be available on any of the default kernels, either at install time or for 99% of post-install systems built from a release. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message