This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: gthread API for c++0x thread lib
On Fri, Aug 8, 2008 at 11:54 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> Chris Fairles wrote:
>>
>> I'm currently attempting to update the gthread API to implement
>> c++0x's thread library. Attached is a half-baked patch with my current
>> progress but besides gthr-posix.h, I'm basically programming blind
>> (i.e. no way to test) and so before I go any further I need some
>> advice/direction on how to progress from here.
>>
>> Thus far I've been stuffing extra function prototypes and def'ns
>> around the ObjC stuff but there's overlap and I'm not sure how to
>> handle it (i.e. duplicated "gthrw" decl's of some pthread funcs).
>> Should any additions required by c++0x be guarded by some defined
>> macro (kind of like the objc stuff is guarded)?
>
> Would you please provide some context about what you're trying to do here?
Certainly. C++0x introduces a new threading library through a few
headers, <thread>, <mutex> and <condition_variable>. Its basically a
stripped down version of boost::thread if you're familiar with it. It
does not support interruption or cancellation.
For <mutex>, the c++ interface exposes recursive and non-recursive
mutex types. Both mutex types require locking indefinitely and with a
timeout specified in either absolute time since some epoch, or
relative time. <condition_variable>'s interface requires typical
"wait", broadcasting to all threads currently waiting and signaling a
single thread currently waiting. It also requires timed waits with the
timeout specified in abs or relative time. The thread class just
requires creation, joining, detaching and "sleeping".
> As I understand it, you need some new functions in the generic thread
> interface to implement new functionality in libstdc++? Is this
> functionality going to be required on all platforms for libstdc++ to
> operate, or is it just required to use the new features?
>
The new functions are only required for the new threading library. The
other parts of libstdc++ that currently use gthreads will function
as-is.
> If the latter, then I would suggest that you focus just on the generic
> "gthr.h" header and the POSIX implementation. Make sure that libstdc++
> checks that the functions are present, either statically (through autoconf
> checks, and remember that you may link -- but not run -- programs to do the
> check), or dynamically (by checking return values). Then, people with other
> threading environments can fill in the blanks as necessary.
>
>From what I understand:
libstdc++'s acinclude.m4 has machinery that executes "gcc -v" grepping
out the "Thread model", then if the gthr-${thread_model}.h exists, it
subts the filename (via glibcxx_thread_h) which is then used
libstdc++'s Makefile.am to create a gthr-default.h using a rule that
basically cats an #include line for the arch specific gthr-*.h into
gthr-default.h and does some replacement of various macros using sed.
I think the idea here is to leverage off of the configuration
machinery in gcc that has already determined the threading model but
I'm not entirely sure how that's accomplished or if extra stuff is
needed in libstdc++ to actually gauruntee the specific functions
exist.
In the Makefile.am, I could cat another macro into gthr-default.h that
would guard the new functions in the arch-specific gthr-*.h's. Or just
use __cplusplus. In any case, I'll only modify posix and single for
now and revert the rest of the junk in the other headers.
> As for Objective-C, you're going to need to track down one of the
> Objective-C maintainers:
>
> objective-c/c++ Mike Stump mrs@apple.com
> objective-c/c++ Stan Shebs stanshebs@earthlink.net
> libobjc Nicola Pero n.pero@mi.flashnet.it
> libobjc Andrew Pinski pinskia@gmail.com
>
> to work out what the interactions are there.
>
Great, I'll follow up with them.
> Thanks,
>
and thank you for the feedback!
Chris
> --
> Mark Mitchell
> CodeSourcery
> mark@codesourcery.com
> (650) 331-3385 x713
>