Date: Tue, 20 Dec 2011 10:09:25 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <201112201009.25534.jhb@freebsd.org> In-Reply-To: <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com> References: <Your message of <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com> <201112200822.26369.jhb@freebsd.org> <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote: > On 20 Dec 2011 at 8:22, John Baldwin wrote: >=20 > > > Everything is the way it is for a good reason. If it doesn't make=20 > > > sense to you that's most likely because you're not half as=20 > > > experienced or clever as you think you are. If you really want to=20 > > > know why something is the way it is, all discussion regarding all=20 > > > points is documented in full. > >=20 > > Mmmm, you might be well served to check up on the experience of some of > > the folks you are conversing with. Otherwise you risk reducing your > > credibility in the present forum. Also, to argue that "everything" in > > a standard is perfect is, eh, a bit of a stretch. There's a reason for > > the connotation associated with the phrase "design by committee". >=20 > That's not what I said John, and I object to you saying that I did. I=20 > said, very specifically, that everything is the way it is for a good=20 > reason. I did not at any stage suggest it was perfect, or right, or=20 > even wise. =46air enough, but I'm not sure I would agree with your definition of "good= "=20 reasons. > > > > Why are fundamentally and necessary programming tools, such as a > > > > "assert this mutex is held" missing ? > > >=20 > > > I think that was rejected due to concerns about introducing race=20 > > > conditions if I remember correctly. You'll generally find there is no= =20 > > > easy way of checking the state of anything threading related for the= =20 > > > same reason. > >=20 > > Err, no, there should be no races here. >=20 > Sorry, I meant race conditions in the way a typical end user=20 > programmer might naively choose to use it. A lot of APIs were dropped=20 > 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 creates a race condition. An assert(), by it's nature, should have no program visi= ble 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 practi= ce nothing is going to use this API for a long while (if ever). On POSIX syst= ems pthreads is going to be more portable and there is a lot of code already=20 written to pthreads. > I might add there is absolutely no reason why implementations can't=20 > add _np extensions. The spec might even add them in a later TR if=20 > they prove common enough. For example, I'd like thread_timedjoin() in=20 > there, but I'll have to get Austin to sign off on pthread_timedjoin()=20 > first. I agree this would be a useful extension. What I would actually like in=20 =46reeBSD-land (and I'm not sure if Apple's libdispatch already does this=20 internally) is to be able to add a kevent() for a thread and have it fire w= hen=20 the thread exits. This would be similar to how a thread in NT becomes=20 signalled when it exits. =2D-=20 John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201112201009.25534.jhb>