[Patch] C1X threading support

[John Baldwin]

On Tuesday, December 20, 2011 9:34:54 am Niall Douglas wrote:
> On 20 Dec 2011 at 8:22, John Baldwin wrote:
> 
> > > Everything is the way it is for a good reason. If it doesn't make 
> > > sense to you that's most likely because you're not half as 
> > > experienced or clever as you think you are. If you really want to 
> > > know why something is the way it is, all discussion regarding all 
> > > points is documented in full.
> > 
> > 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".
> 
> That's not what I said John, and I object to you saying that I did. I 
> said, very specifically, that everything is the way it is for a good 
> reason. I did not at any stage suggest it was perfect, or right, or 
> even wise.

Fair enough, but I'm not sure I would agree with your definition of "good" 
reasons.

> > > > 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.

> I might add there is absolutely no reason why implementations can't 
> add _np extensions. The spec might even add them in a later TR if 
> they prove common enough. For example, I'd like thread_timedjoin() in 
> there, but I'll have to get Austin to sign off on pthread_timedjoin() 
> first.

I agree this would be a useful extension.  What I would actually like in 
FreeBSD-land (and I'm not sure if Apple's libdispatch already does this 
internally) is to be able to add a kevent() for a thread and have it fire when 
the thread exits.  This would be similar to how a thread in NT becomes 
signalled when it exits.

-- 
John Baldwin