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>
index | next in thread | previous in thread | raw e-mail
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ïve use. > > Humm. I fail to see how a user can misuse an assert() in a way that creates > a race condition. An assert(), by it's nature, should have no program visible > 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 practice > nothing is going to use this API for a long while (if ever). On POSIX systems > 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=show_archive.tpl&source=L&listname=austin-group-l&id=11671 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... -- DEhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1112201150420.29118>