[config] policy for setting BOOST_HAS_THREADS?
Hello, What is the policy by which BOOST_HAS_THREADS gets defined or not? I used to think this macro is somehow affected by the selection of a single-threaded or multithreaded runtime library as done in bjam with threading=single and threading=multi, but some experiments in Linux suggest that this is not the case, as discussed in the following thread: http://lists.boost.org/boost-build/2008/11/20641.php Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN M. LOPEZ MUÑOZ wrote:
Hello,
What is the policy by which BOOST_HAS_THREADS gets defined or not? I used to think this macro is somehow affected by the selection of a single-threaded or multithreaded runtime library as done in bjam with threading=single and threading=multi, but some experiments in Linux suggest that this is not the case, as discussed in the following thread:
It's set if the compiler and it's std lib is in thread safe mode. For gcc it's either set or not depending upon how gcc with built (since there are no compiler options that actually change the thread-safeness in recent gcc releases: and yes I checked with the gcc and libstdc++ teams on that!). For other compilers (for example msvc) it may be set or not depending on what compiler options are used. HTH, John.
John Maddock escribió:
JOAQUIN M. LOPEZ MUÑOZ wrote:
Hello,
What is the policy by which BOOST_HAS_THREADS gets defined or not? I used to think this macro is somehow affected by the selection of a single-threaded or multithreaded runtime library as done in bjam with threading=single and threading=multi, but some experiments in Linux suggest that this is not the case, as discussed in the following thread:
It's set if the compiler and it's std lib is in thread safe mode. For gcc it's either set or not depending upon how gcc with built
Sorry, I don't get the last statement :( I understand there's a typo there, but can't make out what the intended phrase was. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
joaquin@tid.es wrote:
Sorry, I don't get the last statement :( I understand there's a typo there, but can't make out what the intended phrase was.
Apologies, I didn't express myself very well. I mean for gcc, the setting of BOOST_HAS_THREADS doesn't change depending upon any compiler options. Rather, whether or not it gets set depends upon how the user configured and installed gcc their copy of gcc. HTH, John.
John Maddock escribió:
joaquin@tid.es wrote:
Sorry, I don't get the last statement :( I understand there's a typo there, but can't make out what the intended phrase was.
Apologies, I didn't express myself very well.
I mean for gcc, the setting of BOOST_HAS_THREADS doesn't change depending upon any compiler options. Rather, whether or not it gets set depends upon how the user configured and installed gcc their copy of gcc.
OK, understood. Then, we have the somewhat unfortunate situation that in GCC environments Boost.Build links / does not link Pthreads depending on whether the threading parameter is multi / single, whereas Boost.Config does not reflect this situation in any manner! As most GCC environments (somebody correct me if I'm wrong) are nowadays multithreaded, would it make sense to change GCC Boost.Build bjam rules so that threading=simple results in BOOST_DISABLE_THREADS being defined? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
joaquin@tid.es wrote:
OK, understood. Then, we have the somewhat unfortunate situation that in GCC environments Boost.Build links / does not link Pthreads depending on whether the threading parameter is multi / single, whereas Boost.Config does not reflect this situation in any manner!
As most GCC environments (somebody correct me if I'm wrong) are nowadays multithreaded, would it make sense to change GCC Boost.Build bjam rules so that threading=simple results in BOOST_DISABLE_THREADS being defined?
Sigh... no, while that would no doubt fix a few tests, what users were asking for (and what we now build by default) is a single binary for gcc/*nix systems that can be used irrespective of whether they're using threads or not. In other words we want to fix the Boost ABI to be the same as the libstdc++ ABI, no matter whether a default threading-single build is done or not. Hope this is making some sense, but I don't know what the correct solution is.... John.
John Maddock
joaquin <at> tid.es wrote:
As most GCC environments (somebody correct me if I'm wrong) are nowadays multithreaded, would it make sense to change GCC Boost.Build bjam rules so that threading=simple results in BOOST_DISABLE_THREADS being defined?
Sigh... no, while that would no doubt fix a few tests, what users were asking for (and what we now build by default) is a single binary for gcc/*nix systems that can be used irrespective of whether they're using threads or not. In other words we want to fix the Boost ABI to be the same as the libstdc++ ABI, no matter whether a default threading-single build is done or not.
What does defining/not defining BOOST_DISABLE_THREADS have to do with the Boost ABI? If currently the only effect of selecting threading=multi/single is whether Pthreads is linked/not linked, then the macro just reflects this into the world of Boost.Config. Is by chance BOOST_HAS_THREADS affecting the lib suffixes used in autolinking mode? If so, maybe the solution is to just adjust the autolinking in Linux appropriately. Sorry if I'm missing something obvious here --I'm sure I am :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz wrote:
What does defining/not defining BOOST_DISABLE_THREADS have to do with the Boost ABI?
It changes the the internal layout of some Boost types, as well as their behaviour. So if we're being asked for a single binary, it had better be thread safe. John.
If currently the only effect of selecting threading=multi/single is whether Pthreads is linked/not linked, then the macro just reflects this into the world of Boost.Config. Is by chance BOOST_HAS_THREADS affecting the lib suffixes used in autolinking mode? If so, maybe the solution is to just adjust the autolinking in Linux appropriately. Sorry if I'm missing something obvious here --I'm sure I am :)
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.9.1/1781 - Release Date: 11/11/2008 08:59
John Maddock wrote:
joaquin@tid.es wrote:
OK, understood. Then, we have the somewhat unfortunate situation that in GCC environments Boost.Build links / does not link Pthreads depending on whether the threading parameter is multi / single, whereas Boost.Config does not reflect this situation in any manner!
As most GCC environments (somebody correct me if I'm wrong) are nowadays multithreaded, would it make sense to change GCC Boost.Build bjam rules so that threading=simple results in BOOST_DISABLE_THREADS being defined?
Sigh... no, while that would no doubt fix a few tests, what users were asking for (and what we now build by default) is a single binary for gcc/*nix systems that can be used irrespective of whether they're using threads or not. In other words we want to fix the Boost ABI to be the same as the libstdc++ ABI, no matter whether a default threading-single build is done or not.
Hope this is making some sense, but I don't know what the correct solution is....
I don't know if the current solution is right. libstdc++ will work no matter if your application is ST or MT -- where "MT" application is defined as application that links to pthread and actually creates multiple threads. But I think it's result of explicit work. In particular: - ABI is the same in ST and MT builds - if application is not linked to pthreads, then libstdc++ will use dummy functions for synchronisation, with almost zero overhead. Boost, on the other hand, does not do anything special. The overhead of locking does not go away if application does not use threads. Therefore, it makes sense to control if that overhead exists -- by explicitly controlling if Boost should be built in ST or MT mode, as selected by 'threading' feature in Boost.Build or by -pthread command line option in gcc. Just always building in MT mode is easy, but I don't know if that's the best solution. - Volodya
Vladimir Prus wrote:
I don't know if the current solution is right.
Nod. BTW I didn't ask for the current situation, it was rather foisted upon us by the change to build and install a single binary. We can fix up Boost.Config to behave any way we want, as long as everyone agrees! :-)
libstdc++ will work no matter if your application is ST or MT -- where "MT" application is defined as application that links to pthread and actually creates multiple threads. But I think it's result of explicit work. In particular:
- ABI is the same in ST and MT builds - if application is not linked to pthreads, then libstdc++ will use dummy functions for synchronisation, with almost zero overhead.
Boost, on the other hand, does not do anything special. The overhead of locking does not go away if application does not use threads.
Unless we're also linking to the dummy pthread lib? I thought that was what happened automatically on Linux at least anyway, unless you explicitly linked to -lpthread?
Therefore, it makes sense to control if that overhead exists -- by explicitly controlling if Boost should be built in ST or MT mode, as selected by 'threading' feature in Boost.Build or by -pthread command line option in gcc.
Just always building in MT mode is easy, but I don't know if that's the best solution.
Nod. As I say, just tell me what the solution is and we can go for it :-) John.
John Maddock wrote:
JOAQUIN M. LOPEZ MUÑOZ wrote:
Hello,
What is the policy by which BOOST_HAS_THREADS gets defined or not? I used to think this macro is somehow affected by the selection of a single-threaded or multithreaded runtime library as done in bjam with threading=single and threading=multi, but some experiments in Linux suggest that this is not the case, as discussed in the following thread:
It's set if the compiler and it's std lib is in thread safe mode. For gcc it's either set or not depending upon how gcc with built (since there are no compiler options that actually change the thread-safeness in recent gcc releases: and yes I checked with the gcc and libstdc++ teams on that!).
How is this related to _REENTRANT been set or not set? Do you have the pointers to your conversations with gcc hackers? - Volodya
Vladimir Prus wrote:
It's set if the compiler and it's std lib is in thread safe mode. For gcc it's either set or not depending upon how gcc with built (since there are no compiler options that actually change the thread-safeness in recent gcc releases: and yes I checked with the gcc and libstdc++ teams on that!).
How is this related to _REENTRANT been set or not set? Do you have the pointers to your conversations with gcc hackers?
_REENTRANT has a somewhat checkered history, because at least historically some gcc std lib headers would set this when they were included. As far as gcc and libstdc++ are concerned they don't use _REENTRANT anywhere. Replies from the gcc mailing lists attached. HTH, John.
participants (5)
-
Joaquin M Lopez Munoz -
JOAQUIN M. LOPEZ MUÑOZ
-
joaquin＠tid.es
-
John Maddock -
Vladimir Prus