deciding threading support at compile time

deciding threading support at compile time

[Christoph Ludwig]

Hi,

with gcc 3.4.0, how can I decide at compile time (e.g., by a
preprocessor constant) whether gcc was called with the '-pthread'
command line option? 

Background: My compiler is configured as follows:

  cludwig@lap200:~/C++/gcc3.4/LaRed2> LANG=C ; g++ -v
  Reading specs from /opt/gcc/gcc-3.4.0/lib/gcc/i686-pc-linux-gnu/3.4.0/specs
  Configured with: ../gcc-3.4.0/configure --prefix=/opt/gcc/gcc-3.4.0
  --enable-threads=posix --enable-version-specific-runtime-libs
  --enable-languages=c,c++ --enable-__cxa_atexit --enable-c-mbchar
  --enable-concept-checks --enable-libstdcxx-debug --enable-c99
  --enable-libstdcxx-pch
  Thread model: posix
  gcc version 3.4.0

When testing gcc 3.4.0 with a program using Boost libraries, I found
that sometimes the preprocessor variable BOOST_HAS_THREADS is
spuriously set if, e.g., the C++ standard string header is included.
This makes the boost::smart_ptr library refer to pthread symbols. In
other translation units that do not include the C++ string header
BOOST_HAS_THREADS is not set whence boost::smart_ptr refers to a dummy
mutex. This is not only an obvious violation of the ODR, but also
causes linker errors. (I gave more details in my posting to the Boost
mailing
list. http://thread.gmane.org/gmane.comp.lib.boost.devel/102817) 

The string header eventually includes the header
c++/i686-pc-linux-gnu/bits/gthr-default.h. Since gcc 3.4, this header
unconditionally defines the preprocessor variable _REENTRANT. (A
rational for this change is given in
http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01607.html.)
But the Boost configuration headers define BOOST_HAS_THREADS if
_REENTRANT is defined.

Hence my questions:
 - Is it correct that _REENTRANT is defined under linux even if the
   compiler was called without '-pthread'? 

 - How can I decide at compile time whether the command line option
   '-pthread' was present? Or whether any other MT-support is active?
   (I was told about __gthread_active_p(), but that does not help at
   *compile* time.)

 - Where can I find comprehensive documentation of the effects of the
   '-pthread' option under Linux on x86? The gcc 3.4.0 manual mentions
   this option as an IBM RS/6000 and PowerPC submodel option
   only. (E.g., does the compiler generate different code for the
   initialization of local static variables if '-pthread' is in
   effect?)

Thanks

Christoph


-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Re: deciding threading support at compile time

[Christoph Ludwig]

Hi Eljay,

On Mon, May 10, 2004 at 11:01:50AM -0500, Eljay Love-Jensen wrote:
> q.v.
> http://vergil.chemistry.gatech.edu/resources/programming/threads.html
> 
> It looks like it is up to YOU to put in the -D_POSIX_PTHREAD_SEMANTICS and 
> -D_REENTRANT on the compile line, and specify -lpthread on the link
> line.

thanks for your quick reply. 

But my problem is not how to compile and link programs using the
pthreads library. In fact, my troubles started when building a single
threaded program...

The question is how can a library writer reliably decide in a header
file whether the program is to support multithreading. (E.g., in a
header-only library like boost::smart_ptr.)

Regards

Christoph
-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

Re: deciding threading support at compile time

[Eljay Love-Jensen]

Hi Christoph,

q.v.
http://vergil.chemistry.gatech.edu/resources/programming/threads.html

It looks like it is up to YOU to put in the -D_POSIX_PTHREAD_SEMANTICS and 
-D_REENTRANT on the compile line, and specify -lpthread on the link line.

Keep in mind, C and C++ do not have a language specification for 
multithreading.  Any multithreading facility is an "aftermarket 
bolt-on".  POSIX threads (pthreads) attempts to make a platform agnostic / 
consistent multithreading experience.

There are languages that do incorporate multithreading into the language 
proper.  For example: Ada, Java and (academic MIT project) Cilk.

HTH,
--Eljay

Re: deciding threading support at compile time

[Eljay Love-Jensen]

Hi Christoph,

You asked...
How can a library writer reliably decide in a header file whether the 
program is to support multithreading?

The answer appears to be:

Document that some define is required when used in conjunction with your 
header file that enables multithreading facilities, such as mutex 
protection, necessary for safe multithreaded operation of your library.

For instance, maybe something like -DBOOST_POSIX_THREADS would be appropriate.

Also of interest is another approach, that taken by Doug Schmidt's ACE 
(http://www.cs.wustl.edu/~schmidt/ACE.html).  Therein, he punted* by 
allowing the POLICY level decision of mutex protection to be at the 
discretion of the library user, by making the mutex a template object that 
could (possibly) be a null_mutex.

HTH,
--Eljay

* Or if you think Doug's idea was a good one (as I do), replace "punted" 
with "was inspired".

Re: deciding threading support at compile time

[Jonathan Wakely]

On Mon, May 10, 2004 at 11:58:09AM -0500, Eljay Love-Jensen wrote:

> You asked...
> How can a library writer reliably decide in a header file whether the 
> program is to support multithreading?
> 
> The answer appears to be:
> 
> Document that some define is required when used in conjunction with your 
> header file that enables multithreading facilities, such as mutex 
> protection, necessary for safe multithreaded operation of your library.
> 
> For instance, maybe something like -DBOOST_POSIX_THREADS would be 
> appropriate.

Boost already contains something similar, allowing you to disable all
mutexes and locks by defining BOOST_DISABLE_THREADS but the point is that
Boost tries to auto-detect your compiler and its features and to provide
consistent, portable functionality without requiring the user to add
explicit defines.

This ensures that locking is not done and the overhead of thread-safety
is avoided when the compiler is not producing a multi-threaded executable.

Previously if Boost was compiled by G++ it assumed that the presence of
the _REENTRANT macro meant "-pthread" had been given. This no longer
works, because G++ unconditionally defines _REENTRANT (for Tru64's
pthread.h implementation). The question is not "how do you use the
preprocessor for conditional compilation" but "does G++ provide an
alternative mechanism to _REENTRANT that would let Boost determine if
the -pthread switch was given on the command line?"

If not, are there good reasons why a _GLIBCXX_REENTRANT macro could not
be defined when "-pthread" is given?

(And would this be better asked on the "gcc" list?)

jon


-- 
"Some people have a way with words.  Others...not have way."
	- Steve Martin