Re: [boost] [thread] call_once doesn't call even once

Subject: Re: [boost] [thread] call_once doesn't call even once
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-10-11 19:02:24

Le 11/10/12 22:48, Kim Barrett a écrit :
> In boost 1.52.0 beta1
>
> In boost/thread/pthread/once.hpp, near the head of the file, is the following conditional snippet:
>
> #ifdef SIG_ATOMIC_MAX
>      typedef sig_atomic_t uintmax_atomic_t;
>      ...
> #else
>      ...
> #endif
>
> Well, sig_atomic_t may be a signed type, and in fact on the Linux system I'm testing on it is a typedef for int [suse12.1, but I suspect it doesn't really matter.]  POSIX says "Possibly volatile-qualified integer type ...".
>
> This led to boost::call_once never calling the function, because there is a comparison in call_once
>    (epoch<this_thread_epoch)
> where I'm seeing values of 0 and -2 respectively for those variables, that doesn't go in the expected direction when uintmax_atomic_t is a signed type rather than the expected unsigned type.  I bet there are other places that get confused by this being an unexpectedly signed type.
>
> I'm working around this to continue my testing of 1.52beta1 by commenting out the offending conditional code and just using the code in the #else clause.
>
> The relevant code is new code, introduced since boost 1.51.  This is a
> serious regression that should be a blocker for the 1.52 release.
>
> I've filed a bug for this:
> https://svn.boost.org/trac/boost/ticket/7499
>
>
>
>
Hi,

this was part of a trial to fix 
https://svn.boost.org/trac/boost/ticket/5752. It seems that this was 
more disturbing than helping. As you can see on the ticket, I will use 
atomic<unsigned long> as soon as Boost.Atomic is part of the release 
branch. I will apply your patch as soon as my tests finish.

Thanks for catching this before 1.52 is delivered,
Vicente