Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Tue, 24 Jul 2001 11:38:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Tue, 24 Jul 2001 11:38:20 -0400 Received: from sncgw.nai.com ([161.69.248.229]:39617 "EHLO mcafee-labs.nai.com") by vger.kernel.org with ESMTP id ; Tue, 24 Jul 2001 11:38:17 -0400 Message-ID: X-Mailer: XFMail 1.4.7 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Tue, 24 Jul 2001 08:41:34 -0700 (PDT) From: Davide Libenzi To: Jonathan Lundell Subject: Re: user-mode port 0.44-2.4.7 Cc: Jan Hubicka , linux-kernel@vger.kernel.org, user-mode-linux-user@lists.sourceforge.net, Jeff Dike , Andrea Arcangeli , Linus Torvalds Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Original-Recipient: rfc822;linux-kernel-outgoing On 24-Jul-2001 Jonathan Lundell wrote: > At 3:51 PM -0700 2001-07-23, Linus Torvalds wrote: >>On Mon, 23 Jul 2001, Jonathan Lundell wrote: >>> >>> If jiffies were not volatile, this initializing assignment and the >>> test at the end could be optimized away, leaving an unconditional >>> "return 0". A lock is of no help. >> >>Right. >> >>We want optimization barriers, and there's an explicit "barrier()" thing >>for Linux exactly for this reason. >> >>For historical reasons "jiffies" is actually marked volatile, but at least >>it has reasonably good semantics with a single-data item. Which is not to >>say I like it. But grep for "barrier()" to see how many times we make this >>explicit in the algorithms. >> >>And really, THAT is my whole point. Notice in the previous mail how I used >>"volatile" when it was part of the _algorithm_. You should not hide >>algorithmic choices in your data structures. You should make them >>explicit, so that when you read the code you _see_ what assumptions people >>make. > > OK, sure, that's fine. Better than barrier() in some respects, too. > Namely, 1) volatile is portable C; barrier() isn't (not that that's > much of an issue for compiling Linux), and 2) volatile can be > specific to a variable, unlike the indiscriminate barrier(), which > forces a reload of everything that might be cached (OK, not a big > deal for IA32, but nontrivial for many-register architectures). One > could imagine a more specific barrier(jiffies) syntax, I suppose, but > the volatile cast is nice, restricting the effect not only to the > single variable but to the single reference to a single variable. One more thing, with volatile you specify it one time ( declaration time ), while with barrier() you've to spread inside the code tons of such macro everywhere you touch the variable. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/