Re: deciding threading support at compile time

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

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