Date: Mon, 12 Jul 1999 17:11:48 +0800 From: Peter Wemm <peter@netplex.com.au> To: Doug Rabson <dfr@nlsystems.com> Cc: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au>, mike@ducky.net, freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <19990712091149.0837981@overcee.netplex.com.au> In-Reply-To: Your message of "Mon, 12 Jul 1999 09:00:59 %2B0100." <Pine.BSF.4.10.9907120859240.52933-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Doug Rabson wrote: > On Mon, 12 Jul 1999, Peter Jeremy wrote: > > > 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'). > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990712091149.0837981>