Peter Dimov wrote:
Another observation: the difference between g++/Sun in ST and MT mode:
http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-boo...
is in the _PTHREADS macro (_REENTRANT is defined in both cases, which causes BOOST_HAS_THREADS and BOOST_HAS_PTHREADS to be defined as well even in ST mode.)
OK, I've taken a shot at fixing this, but I don't have Solaris to test on, so <shrug> ! Basically <unistd.h> always advertises the presence of pthreads on Solaris so BOOST_HAS_PTHREADS gets set regardless. I've now added an additional check to solaris.hpp to turn it off for gcc when _PTHREADS is not set. I've also beefed up the pthread test cases: they now create a thread, join and do a try lock as requested.
Taking a Linux g++ at random:
http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-boo...
http://www.boost.org/development/tests/trunk/developer/output/Sandia-gcc-boo...
_REENTRANT is correctly only defined in MT mode, but BOOST_HAS_THREADS (and BOOST_HAS_PTHREADS) incorrectly remains defined in both.
g++ 4.1 also seems to work the same way, whereas g++ 4.0 and g++ 3.4 do not, they always define _REENTRANT and there doesn't seem to be a way to detect MT mode (at least judging by the output of config_info).
Yeh, g++ has always been lax about advertising whether it's in thread safe mode or not. Lets see where these changes get us, and then we need to decide what to do on Win32 in strict mode when <windows.h> is unavailable :-) John.