Date: Tue, 20 Dec 2011 19:17:36 -0000 From: "Niall Douglas" <s_sourceforge@nedprod.com> To: freebsd-threads@freebsd.org Subject: Re: [Patch] C1X threading support Message-ID: <4EF0DF50.9243.B766CF98@s_sourceforge.nedprod.com> In-Reply-To: <201112201009.25534.jhb@freebsd.org> References: <Your message of <4EF059DC.26433.B55D8036@s_sourceforge.nedprod.com>, <4EF09D0E.14095.B663FD3C@s_sourceforge.nedprod.com>, <201112201009.25534.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 "goo= d" > 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=EFve use. > > Humm. I fail to see how a user can misuse an assert() in a way that cre= ates > a race condition. An assert(), by it's nature, should have no program v= isible > changes. If the programmer puts the assertion in the wrong place then i= t > 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 assertio= n 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 pra= ctice > nothing is going to use this API for a long while (if ever). On POSIX s= ystems > 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 fir= e 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EF0DF50.9243.B766CF98>