Date: Mon, 12 Jul 1999 08:52:56 +0100 (BST) From: Doug Rabson <dfr@nlsystems.com> To: Mike Haertel <mike@ducky.net> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Alan Cox <alc@cs.rice.edu>, Stephen McKay <syssgm@detir.qld.gov.au>, Andrew Gallatin <gallatin@cs.duke.edu>, freebsd-current@freebsd.org Subject: Re: "objtrm" problem probably found (was Re: Stuck in "objtrm") Message-ID: <Pine.BSF.4.10.9907120850570.52933-100000@salmon.nlsystems.com> In-Reply-To: <199907112249.PAA16398@ducky.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 Jul 1999, Mike Haertel wrote: > >On Sat, 10 Jul 1999, Matthew Dillon wrote: > >> > >> The supposedly atomic functions in i386/include/atomic.h are not > >> as atomic as was previously thought :-): > >> > >> #define atomic_add_short(P, V) (*(u_short*)(P) += (V)) > >[...] > > > >Before I fixed this stuff for the alpha, the += expressions were > >scattered all over the source tree. At least you get to fix the macro :-). > > 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 guess I should clarify what I mean by atomic: > > "addl $1, foo" is atomic with respect to interrupts. > However, it is not atomic with respect to other processors, > i.e is not SMP safe. > > "lock addl $1, foo" is both atomic with respect to > interrupts, and also with respect to activity by > the other processor. I know about this. We (currently) only need it to be atomic wrt interrupts and the i386 header file states this explicitly. The alpha versions of this are SMP safe simply because the code sequence which was interrupt safe was the same. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 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?Pine.BSF.4.10.9907120850570.52933-100000>