Re: [boost] BOOST_HAS_THREADS and gcc

From: John Maddock (john_at_[hidden])
Date: 2008-04-12 05:11:11

Peter Dimov wrote:
>> 2) In a sense gcc is either "always thread safe" or "never thread
>> safe" depending on how it and libstdc++ were built.  For example on
>> Linux (and most other platforms I believe) -pthread does nothing
>> except
>> pass -lpthread
>> to the linker.
>>
>> So... assuming (1) really has been fixed in gcc-4.1, what's the right
>> thing
>> to do about (2)?
>
> Good question. :-/
>
> We have four options for the <threading>single case:
>
> 1. !HAS_THREADS, !HAS_PTHREADS
> 2. HAS_THREADS, !HAS_PTHREADS
> 3. HAS_THREADS, HAS_PTHREADS
> 4. HAS_THREADS, HAS_PTHREADS, add -lpthread
>
> I really have no idea which of these is best. I can see arguments for
> each. If .o files compiled with and without -pthread are indeed link
> compatible, our current choice of (3) seems pretty reasonable.

A quick servey of the GCC manual found these entries for -pthread:

-pthread Add support for multithreading using the POSIX threads library. 
This option
sets flags for both the preprocessor and linker. It does not affect the 
thread
safety of object code produced by the compiler or that of libraries supplied 
with
it. These are HP-UX specific flags.

-pthread Adds support for multithreading with the pthreads library. This 
option sets
flags for both the preprocessor and linker.

-pthreads
Add support for multithreading using the POSIX threads library. This option
sets flags for both the preprocessor and linker. This option does not affect
the thread safety of object code produced by the compiler or that of 
libraries
supplied with it.
-pthread This is a synonym for '-pthreads'.

So on all platforms that support this, it changes the linker flags and the 
preprocessor defines but that's it.

> A practical problem I have with (3) is that pthread_mutex_trylock
> links and crashes. But I'm not sure whether this warrants any
> changes. Maybe the correct way to deal with it is to mark it up and
> move on.

Do you have a test case?

> If we do choose to stay with (3) as our choice, we probably need to
> revert the has_pthreads test back to the stubs and move the real
> has_pthreads (and has_pthread_mutexattr_settype) to separate tests
> outside of config_test.

Sigh :-(

Yep.

Still not sure what the right answer is yours, John.