[Patch] C1X threading support

[Niall Douglas]

On 20 Dec 2011 at 10:09, John Baldwin wrote:

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

Maybe it's a difference in US vs UK English :). By "good" I equally 
mean "sound" or "valid". 

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

My statements come from my (prolonged) efforts to develop a safe 
permit threading object for C11 as people have the tendency to roll 
their own buggy implementations which just don't work right. This was 
based on the Java permit primitive, but because C has function 
pointers it is more flexible. You can see the last public version of 
this at https://github.com/ned14/C1Xstuff/tree/ISO_TS_pre/N1572. BTW, 
it needs splitting into two implementations, one for single releaser 
and the other for multi releaser.

During the very drawn out process of consulting with everyone who has 
a stake in this, I probably talked to almost everyone who contributed 
to the threading libraries of C (and indeed C++). The fact they 
repeatedly beat my design and implementation into pieces was 
immensely frustrating but in hindsight they were right. As much as 
it's design by committee, there is one hell of a lot of talent in 
that pool.

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

What's supposed to happen is that the C++ threading layer is going to 
be implemented using the C threading layer - hence the need for 
feature parity. I would imagine that will expose a whole load of 
issues not previously thought through. It certainly ought to be first 
test of the C API in anger anyway.

I think for new code written to run across systems the new API will 
be very useful. Not everything runs POSIX after all. Even with its 
warts that will drive adoption.

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

I would personally call it vital in C11, because thread_join() is one 
of the very few places a process can deadlock because there is no 
timed variant. You can avoid pthread_timedjoin() because you have 
thread cancellation, but without cancellation thread_join() leaves 
you no option for catching deadlock at all. This is fatal in C11 and 
it needs to be fixed urgently.

Usefully all major POSIX implementations (including BSD) already 
implement pthread_timedjoin_np(). I just need to get around to 
kicking the ball rolling in the Austin WG.

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

Oh my and you are on the same page ... my proposals for standardising 
kernel queues got completely shat all over. I also wanted a standard 
API for reading the local process memory map rather than relying on 
reading from /proc and another such that a piece of calling code can 
discover which shared object it is currently executing from (this is 
very useful for binding translations to that which uses them). All 
sadly binned due to lack of established practice.

I also want a batch API for all calls where this makes sense :). It 
would be real nice if you could batch stat() and batch malloc() etc. 
But that'll be long down the line I'd say.

Niall

-- 
Technology & Consulting Services - ned Productions Limited.
http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 
472909.