Date: Thu, 3 Jan 2002 12:22:34 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, Peter Jeremy <peter.jeremy@alcatel.com.au>, Michal Mertl <mime@traveller.cz>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, <arch@FreeBSD.ORG> Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <Pine.BSF.4.33.0201031218230.65479-100000@herring.nlsystems.com> In-Reply-To: <200201030158.g031wWD61364@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2 Jan 2002, Matthew Dillon wrote: > :> section is dropped. If an interrupt occurs on the cpu while the current > :> thread is in a critical section, it should be deferred just like we > :> did with _cpl in our spl*() code. > : > :Have you even looked at the current implementation? :) > > Yes, I have John. Perhaps you didn't read the part of my email > that indicated most of the critical sections we have in the system > are top-level sections. Optimizing the nesting is all well and fine > but it isn't going to improve peformance. > > Let me put this in perspective, to show you how twisted the code > has become. > > * Because preemption can cause a thread to resume on a different cpu, > the per-cpu area pointer is not consistent and per-cpu variables > must be accessed atomically with the pointer. Even per-cpu variables must often be accessed atomically. The original reason for adding the atomic_ apis was to make updates to counters and flags variables safe in the presence of interrupts (not SMP at all). Non x86 architectures cannot update a memory location with a single instruction and it was necessary to use the atomic_ apis to protect against interrupts on a single cpu. Later on, even x86 needed this when the compiler changed to use read-modify-write sequences for updates to memory location. Whatever you do for SMP and per-cpu stuff, you will never be able to safely write '++*p' on non-x86 architectures. -- Doug Rabson Mail: dfr@nlsystems.com Phone: +44 20 8348 6160 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" 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.33.0201031218230.65479-100000>