Date: Tue, 20 Dec 2011 11:56:45 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <Pine.GSO.4.64.1112201150420.29118@sea.ntplx.net> In-Reply-To: <201112201009.25534.jhb@freebsd.org> References: <Your message of <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> <201112201009.25534.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1112201150420.29118>