Date: Mon, 19 Dec 2011 19:36:21 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: arch@freebsd.org, threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EEF9235.252.B2519BEE@s_sourceforge.nedprod.com> In-Reply-To: <86ty4y4rj5.fsf@ds4.des.no> References: <85477.1324155737@critter.freebsd.dk>, <86ty4y4rj5.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Dec 2011 at 2:06, Dag-Erling Sm=F8rgrav wrote: > "Poul-Henning Kamp" <phk@phk.freebsd.dk> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EEF9235.252.B2519BEE>