From owner-freebsd-arch@FreeBSD.ORG Mon Dec 19 19:36:29 2011 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AC3E106564A; Mon, 19 Dec 2011 19:36:29 +0000 (UTC) (envelope-from s_sourceforge@nedprod.com) Received: from europe2.nedproductions.biz (unknown [IPv6:2a02:748:100:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B1AB98FC13; Mon, 19 Dec 2011 19:36:28 +0000 (UTC) Received: by europe2.nedproductions.biz (Postfix, from userid 1003) id 0968A9EE476; Mon, 19 Dec 2011 19:36:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323388; bh=kAA7hcQIbkEDdfBCWO/gz0tn+ryUvDyiHQL82jX1ZwE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=sGN3zTM5wFrBsBycpiOOEU57fSC1yChY1WUMgnm0/uxoq+ThQpO5jUQf+aCUkBZCH y22yazHUejmqCgPs5dvvgUJp2ZLrPInKVutVcFxlCbLNMxJ3HbTn5L75dVJxFja/Kc WQdIo4PD/qp8MXUtuAe41aVYpt4f8K39lQP6njzg= X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on europe2.nedproductions.biz X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from [192.168.2.8] (dsl-076-041.cust.imagine.ie [87.232.76.41]) by europe2.nedproductions.biz (Postfix) with ESMTPSA id 86D949EE473; Mon, 19 Dec 2011 19:36:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nedprod.com; s=mail; t=1324323387; bh=kAA7hcQIbkEDdfBCWO/gz0tn+ryUvDyiHQL82jX1ZwE=; h=From:To:Date:MIME-Version:Subject:Message-ID:In-reply-to: References:Content-type:Content-transfer-encoding: Content-description; b=AEPh5XOpRcE+712kIFxhqbcav6QC5oO0HhOV52BVc9N9CgvwHknERvNYgSzHGLkK3 olbRU7zhEISxPbSy8xPDXwiMPcdDJIbVocY8uo7zmLB5J1Aztku6TpinFZAykUJ5kx GUwNeGeBtgv4uym0Drkc9PbubqJ3zutIFN9oVMME= From: "Niall Douglas" To: arch@freebsd.org, threads@freebsd.org Date: Mon, 19 Dec 2011 19:36:21 -0000 MIME-Version: 1.0 Message-ID: <4EEF9235.252.B2519BEE@s_sourceforge.nedprod.com> Priority: normal In-reply-to: <86ty4y4rj5.fsf@ds4.des.no> References: <85477.1324155737@critter.freebsd.dk>, <86ty4y4rj5.fsf@ds4.des.no> X-mailer: Pegasus Mail for Windows (4.62) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: Quoted-printable Content-description: Mail message body Cc: Subject: Re: [Patch] C1X threading support 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: Mon, 19 Dec 2011 19:36:29 -0000 On 18 Dec 2011 at 2:06, Dag-Erling Sm=F8rgrav wrote: > "Poul-Henning Kamp" writes: > > Ohhh, but I know: Lets make a rival to the POSIX threads, we can do i= t > > much better and slightly incompatible, big market there I'm sure. > > That's not the point. The point is that C until now did not have a > concurrency model. The threading API in itself is not important; I'm > sure the committee knows perfectly well that nobody is going to use it. > What's important is that the standard now defines how C behaves in a > concurrent environment. Actually we don't go far enough at all in specifying how C behaves in a concurrent environment. The problem is that in the expected lifetime of the standard (10 years) there are a number of known big changes coming to commodity hardware e.g. memory transactions and non-SMP cache coherency. No one on the committee wants to accidentally break future hardware features, so we have left them unspecified. BTW we entirely expect the C1X threading API to supplant all others, including POSIX whose threading support will be mostly for backwards compatibility and may even become deprecated. A lot of resources and effort has been directed into getting the memory model right and future safe if not future proof. Indeed, the chances are that the next POSIX revision will copy C1X in some areas rather than the other way round. The complaints about API bloating are obvious. Bear in mind that while POSIX based platforms are in a majority, there are significant large implementors of C1X for whom a lot of new support code will have to be written e.g. MS Windows, whereas POSIX platforms have a much easier time of things in supporting C1X. Regarding implementing support for the C1X threading API, I'd suggest a different approach. Windows PE and Apple Mach-O both support symbol aliasing so you can declare an API to be identical to another API. Interestingly, ELF has no such feature. See http://blog.omega-prime.co.uk/?p=3D121. I would suggest the best and easiest way to implement much of the C1X library is to add symbol aliasing to ELF. Then all ELF binary based systems could support C1X features without having to resort to inline headers or thin wrappers. Linux will be needing this too, and it's the easiest way out. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909.