From owner-freebsd-arch@FreeBSD.ORG Tue Oct 30 18:22:56 2007 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E92316A417; Tue, 30 Oct 2007 18:22:56 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id AD4DE13C4A3; Tue, 30 Oct 2007 18:22:55 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp009-s [10.150.69.72]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id l9UI0rdp004337; Tue, 30 Oct 2007 11:00:53 -0700 (PDT) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp009/MantshX 4.0) with ESMTP id l9UI0orY028387 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2007 11:00:51 -0700 (PDT) Message-Id: <60B5543F-CB5D-4E1C-8F36-5BAE1818D1CE@mac.com> From: Marcel Moolenaar To: Poul-Henning Kamp In-Reply-To: <33676.1193689342@critter.freebsd.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Tue, 30 Oct 2007 11:00:48 -0700 References: <33676.1193689342@critter.freebsd.dk> X-Mailer: Apple Mail (2.912) Cc: Ivan Voras , freebsd-arch@freebsd.org Subject: Re: C++ in the kernel X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Oct 2007 18:22:56 -0000 On Oct 29, 2007, at 1:22 PM, Poul-Henning Kamp wrote: > For instance, the entire "dual-address space" dictomy og system > calls/copy{in,out} and the very concept of interrupts are very > tricky to sensibly express in anything but C. Serialization and multi-threading is another thing that cannot be expressed in or isn't part of the language and as such a possible cause for bugs. Those bugs are the result of invalid compiler optimizations -- that is valid in the normal case, but invalid related to locking or multi-threading. Think for example about common sub-expression elimination (CSE) in the context of: lock() a1 = x ... x = a2 unlock() ... lock() b1 = x ... x = b2 unlock() If the compiler knows that lock() and unlock() cannot change the value of x (by virtue of making lock() and unlock() pure and side-effect free) then it may end up generating: c = x ... lock() a1 = c ... x = a2 unlock() ... lock() b1 = c ... x = b2 unlock() Now we have a reference to x that's not protected by the lock and doesn't take multi-threading into account (i.e. the second load cannot be eliminated because x may have changed) and may result in runtime failures. Making x volatile is just a pessimization because that prevents valid CSE operations. See also: Hans Boehm, Reordering constraints for pthread-style locks, ACM SIGPLAN, 2007 http://portal.acm.org/citation.cfm?id=1229470 -- Marcel Moolenaar xcllnt@mac.com