From owner-freebsd-arch Thu Jan 3 4:23:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by hub.freebsd.org (Postfix) with ESMTP id 1DA1C37B416; Thu, 3 Jan 2002 04:23:52 -0800 (PST) Received: from [62.49.251.130] (helo=herring.nlsystems.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 16M6uU-000BmM-0X; Thu, 3 Jan 2002 12:23:50 +0000 Received: from herring (herring [10.0.0.2]) by herring.nlsystems.com (8.11.2/8.11.2) with ESMTP id g03CMY970532; Thu, 3 Jan 2002 12:22:34 GMT (envelope-from dfr@nlsystems.com) Date: Thu, 3 Jan 2002 12:22:34 +0000 (GMT) From: Doug Rabson To: Matthew Dillon Cc: John Baldwin , Peter Jeremy , Michal Mertl , Bruce Evans , Mike Smith , Bernd Walter , Subject: Re: When to use atomic_ functions? (was: 64 bit counters) In-Reply-To: <200201030158.g031wWD61364@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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