From owner-freebsd-threads@FreeBSD.ORG Tue Dec 20 17:19:55 2011 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39D85106564A; Tue, 20 Dec 2011 17:19:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id C57278FC19; Tue, 20 Dec 2011 17:19:54 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id pBKGujYV032515; Tue, 20 Dec 2011 11:56:45 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.6 (mail.netplex.net [204.213.176.10]); Tue, 20 Dec 2011 11:56:45 -0500 (EST) Date: Tue, 20 Dec 2011 11:56:45 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: John Baldwin In-Reply-To: <201112201009.25534.jhb@freebsd.org> Message-ID: References: <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> <201112201009.25534.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-851401618-1324400205=:29118" Cc: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 17:19:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-851401618-1324400205=:29118 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 20 Dec 2011, John Baldwin wrote: > On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote: > >>>>> Why are fundamentally and necessary programming tools, such as a >>>>> "assert this mutex is held" missing ? >>>> >>>> I think that was rejected due to concerns about introducing race >>>> conditions if I remember correctly. You'll generally find there is no >>>> easy way of checking the state of anything threading related for the >>>> same reason. >>> >>> Err, no, there should be no races here. >> >> Sorry, I meant race conditions in the way a typical end user >> programmer might naively choose to use it. A lot of APIs were dropped >> or modified to help inhibit the damage from na=EFve use. > > Humm. I fail to see how a user can misuse an assert() in a way that crea= tes > a race condition. An assert(), by it's nature, should have no program vi= sible > changes. If the programmer puts the assertion in the wrong place then it > may very well lead to false positives, but that is true of any assertion.= I > can understand why you may not want users to use the equivalent of an > 'islocked' function (I'm not a big fan of those myself), but an assertion= is > weaker than an 'islocked' function. > > We could look at adding an _np extension. However, I expect that in prac= tice > nothing is going to use this API for a long while (if ever). On POSIX sy= stems > pthreads is going to be more portable and there is a lot of code already > written to pthreads. And that is exactly the point that Butenhof makes in this comment about the ISO C standard 3 years ago: https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=3Dshow_archive.= tpl&source=3DL&listname=3Daustin-group-l&id=3D11671 His comments are a good read, and are still being echoed in this thread. I wonder how much the final standard changed from the working standard to which his comments pertain... --=20 DE ---559023410-851401618-1324400205=:29118--