This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Improving --enable-libstdcxx-time


We need to do something about the fact that this_thread::yield() and
this_thread::sleep_for() are only defined when GCC is built with
--enable-libstdcxx-time, which most users and distros don't do.

Currently the option defaults to no, which means we don't even try to
use clock_gettime, nanosleep and sched_yield even though they may be
available. The reason is that some or all of those calls are defined
in librt, but on GNU/Linux if libstdc++.so links to librt.so then it
also links to libpthread.so and so __gthread_active_p() will always
return true, causing additional locking in single-threaded apps.  But
on (at least) Solaris librt.so doesn't depend on libpthread.so and we
could always use clock_gettime without performance penalties.

I don't see why the checks for sched_yield (needed by
this_thread::yield), nanosleep (needed for this_thread::sleep_for) and
gettimeofday (used if clock_gettime isn't available) are disabled by
default, they don't need librt, so we should always check for them in
configure and define the _GLIBCXX_USE_... macros. That could either be
done independently of --enable-libstdcxx-time or by making
--enable-libstdcxx-time=yes the default. Even if sched_yield is not
found, I don't think this_thread::yield() is actually required to do
anything, so it could be defined as a no-op (maybe defining
__gthread_yield() as a weak symbol?) for when sched_yield isn't
available.

I think defaulting to --enable-libstdcxx-time=yes would give an more
complete <chrono> and <thread> implementation on most platforms.  Are
there any reason not to do that?

To get maximum clock resolution on GNU/Linux it's still necessary to
use --enable-libstdcxx-time=rt, causing a performance hit in
single-threaded code that uses libstdc++.  That could be solved by
splitting libstdc++.so into two, the existing lib and a new one
providing system_clock::now() (and maybe the C++11 thread classes.)
Progams that don't use system_clock and don't use threads would only
link to libstdc++.so, programs that do use them would link to some
extra lib, say libstdc++11.so, which links to libpthread.so and also
links to librt.so if configured with --enable-libstdcxx-time=rt.

That would solve another minor problem: It was recently pointed out to
me that requiring -pthread to use std::thread is a leaky abstraction
because users of std::thread shouldn't need to know it's implemented
in terms of pthreads. If there was a separate library providing the
C++11 thread features then users could use -lstdc++11 to enable them,
and libpthread.so and librt.so would be automatically linked to if
needed.  We could add a -cxxthread switch which would expand to
-lstdc++11 and would be relevant to all thread models and platforms so
would be portable (which -pthread isn't), documented (which -pthread
isn't), and not require users to know that they need to use -pthread
to enable std::thread.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]