Boost C++ Libraries: Ticket #5752: boost::call_once() is unreliable on some platforms

component changed; cc set

viboes — Sun, 04 Dec 2011 01:08:59 GMT

cc viboes added
component threads → thread

keywords set

viboes — Sun, 11 Dec 2011 15:18:53 GMT

keywords once added

viboes — Sat, 14 Jul 2012 19:15:36 GMT

I would like to make it more reliable, but I don't know on which platforms uintmax_t is unreliable and which type will be reliable for these platforms. Is sig_atomic_t available and reliable on these platforms? Could some one help on this?

owner, status changed

viboes — Sun, 12 Aug 2012 19:35:39 GMT

owner changed from Anthony Williams to viboes
status new → assigned

viboes — Sat, 18 Aug 2012 14:36:57 GMT

Does sig_atomic_t works for you?

milestone changed

viboes — Sat, 18 Aug 2012 14:43:37 GMT

milestone To Be Determined → Boost 1.52.0

Committed in trunk revision [80078].

milestone changed

viboes — Sun, 19 Aug 2012 15:48:28 GMT

milestone Boost 1.52.0 → To Be Determined

Committed in trunk revision [80082].

milestone changed

viboes — Tue, 21 Aug 2012 05:17:15 GMT

milestone To Be Determined → Boost 1.52.0

fhess — Mon, 03 Sep 2012 14:03:01 GMT

When SIG_ATOMIC_MAX is defined (that is, when I compile on Linux with g++ 4.4.5 and -std=c++0x) call_once does not work. It never calls my function at all. I debugged it, it happens because in thread/pthread/once.hpp in the call_once method it compares epoch and this_thread_epoch. epoch is set to 0 and this_thread_epoch is set to -1 so the comparison is false and call once does nothing. It seems the problem is due to uintmax_atomic_t being defined as a sig_atomic_t which turns out to be a signed rather than unsigned type.

fhess — Mon, 03 Sep 2012 14:55:11 GMT

Some more info, it seems the problem is due to SIG_ATOMIC_MAX being defined in my code when I include once.hpp, but it is not defined in once.cpp when the libboost_thread is compiled. By default, cstdint doesn't define SIG_ATOMIC_MAX when compiling in c++ mode, unless you define __STDC_LIMIT_MACROS before stdint.h is included.

cc changed

Frank Mori Hess — Mon, 03 Sep 2012 15:10:01 GMT

cc fmhess@… added

viboes — Sun, 09 Sep 2012 13:24:04 GMT

I will add it

Index: pthread/once.hpp
===================================================================
--- pthread/once.hpp	(revision 80450)
+++ pthread/once.hpp	(working copy)
@@ -17,6 +17,8 @@
 #include <boost/thread/pthread/pthread_mutex_scoped_lock.hpp>
 #include <boost/cstdint.hpp>
 #include <boost/thread/detail/delete.hpp>
+// Force SIG_ATOMIC_MAX tobe defined
+#define __STDC_LIMIT_MACROS
 #include <csignal>
 #include <boost/config/abi_prefix.hpp>

viboes — Sun, 09 Sep 2012 14:48:39 GMT

Committed in trunk revision 80466.

Frank Mori Hess — Sun, 09 Sep 2012 15:25:06 GMT

SIG_ATOMIC_MAX actually gets defined by stdint.h/cstdint not csignal so it seems like your define should be earlier. Actually, even then there's still a problem since the user might include stdint.h before they include the once.hpp, without having __STD_LIMIT_MACROS defined. In that case, SIG_ATOMIC_MAX won't be defined in their code but it will be defined in the thread library, leading to incompatible types again.

viboes — Thu, 13 Sep 2012 19:17:15 GMT

Replying to fmhess:

SIG_ATOMIC_MAX actually gets defined by stdint.h/cstdint not csignal so it seems like your define should be earlier. Actually, even then there's still a problem since the user might include stdint.h before they include the once.hpp, without having __STD_LIMIT_MACROS defined. In that case, SIG_ATOMIC_MAX won't be defined in their code but it will be defined in the thread library, leading to incompatible types again.

It seems then that I can not relay on whether SIG_ATOMIC_MAX is defined or not, but I need a value to mean not-a-valid value. Have a suggestion?

Frank Mori Hess — Fri, 14 Sep 2012 00:45:02 GMT

Replying to viboes:

It seems then that I can not relay on whether SIG_ATOMIC_MAX is defined or not, but I need a value to mean not-a-valid value. Have a suggestion?

How about using a boost::atomic<unsigned long> for the epoch?

milestone changed

viboes — Mon, 17 Sep 2012 21:35:34 GMT

milestone Boost 1.52.0 → To Be Determined

Replying to fmhess:

Replying to viboes:

It seems then that I can not relay on whether SIG_ATOMIC_MAX is defined or not, but I need a value to mean not-a-valid value. Have a suggestion?

How about using a boost::atomic<unsigned long> for the epoch?

I will try to use it when released. I can not depend on a non released library.

kab@… — Thu, 11 Oct 2012 23:22:15 GMT

Replying to fhess:

When SIG_ATOMIC_MAX is defined ... call_once does not work. ... It seems the problem is due to uintmax_atomic_t being defined as a sig_atomic_t which turns out to be a signed rather than unsigned type.

This problem with using sig_atomic_t has been reported separately: https://svn.boost.org/trac/boost/ticket/7499 Too bad I didn't know about this sooner.

attachment set

Andrey Semashev — Sun, 13 Jan 2013 20:31:41 GMT

attachment → atomic_once.patch

The patch ports POSIX implementation of call_once to Boost.Atomic.

milestone changed

viboes — Mon, 14 Jan 2013 23:31:26 GMT

milestone To Be Determined → Boost 1.53.0

viboes — Wed, 16 Jan 2013 21:53:09 GMT

Committed in trunk revision [82513].

milestone changed

viboes — Sun, 27 Jan 2013 15:18:29 GMT

milestone Boost 1.53.0 → Boost 1.54.0

status changed; resolution set

viboes — Sat, 16 Feb 2013 21:45:26 GMT

status assigned → closed
resolution → fixed

merged from trunk [82838]