Doug Rabson wrote:
> On Mon, 12 Jul 1999, Peter Jeremy wrote:
>
> > Mike Haertel <[EMAIL PROTECTED]> 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 - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
