升压TIMED_WAIT闰秒问题 [英] Boost timed_wait leap seconds problem

问题描述

我使用从boost C ++库的TIMED_WAIT，我得到一个问题闰秒。

I am using the timed_wait from boost C++ library and I am getting a problem with leap seconds.

下面是一个快速测试：

#include <boost/thread.hpp>
#include <stdio.h>
#include <boost/date_time/posix_time/posix_time.hpp>

int main(){
        // Determine the absolute time for this timer.
        boost::system_time tAbsoluteTime = boost::get_system_time() + boost::posix_time::milliseconds(35000);

        bool done;
        boost::mutex m;
        boost::condition_variable cond;

        boost::unique_lock<boost::mutex> lk(m);
        while(!done)
        {
            if(!cond.timed_wait(lk,tAbsoluteTime))
            {
                done = true;
                std::cout << "timed out";
            }
        }
        return 1;
}

该TIMED_WAIT函数返回比它应该早点24秒。 24秒是UTC闰秒的电流量。

The timed_wait function is returning 24 seconds earlier than it should. 24 seconds is the current amount of leap seconds in UTC.

因此​​，升压被广泛使用，但我找不到任何关于这方面的问题的任何信息。有没有其他人遇到这个问题？什么是可能的原因和解决办法？

So, boost is widely used but I could not find any info about this particular problem. Has anyone else experienced this problem? What are the possible causes and solutions?

注：我使用升压1.38 Linux系统上。我听说，这个问题不会在MacOS发生。

Notes: I am using boost 1.38 on a linux system. I've heard that this problem doesn't happen on MacOS.

更新：多一点信息：这是在2红帽机器发生内核2.6.9。我已经执行了同样的code Ubuntu主机与内核2.6.30和计时器的行为与预期。

UPDATE: A little more info: This is happening on 2 redhat machines with kernel 2.6.9. I have executed the same code on an ubuntu machine with kernel 2.6.30 and the timer behaves as expected.

所以，我认为，这可能是由操作系统或通过在红帽机器的一些错误配置的设置引起的。

So, what I think is that this is probably being caused by the OS or by some mis-set configuration on the redhat machines.

我有codeD的调节时间，以UTC与比这种调整得到的差异，并添加到原来的时间解决。这个作用似乎像一个坏主意，我因为如果code是没有这个问题的机器上运行，它可能是24S AHEAD。还是没找到这样做的原因。

I have coded a workaround that adjusts the time to UTC and than get the difference from this adjustment and add to the original time. This seens like a bad idea to me because if this code is executed on a machine without this problem, it might be 24s AHEAD. Still could not find the reason for this.

推荐答案

好吧，这里是我做的。这是一个解决办法，我不喜欢它，但它是我能拿出最好的：

Ok, here is what I did. It's a workaround and I am not happy with it but it was the best I could come up with:

int main(){
        typedef boost::date_time::c_local_adjustor<boost::system_time> local_adj;

        // Determine the absolute time for this timer.
        boost::system_time tAbsoluteTime = boost::get_system_time() + boost::posix_time::milliseconds(25000);

        /*
         * A leap second is a positive or negative one-second adjustment to the Coordinated
         * Universal Time (UTC) time scale that keeps it close to mean solar time.
         * UTC, which is used as the basis for official time-of-day radio broadcasts for civil time,
         * is maintained using extremely precise atomic clocks. To keep the UTC time scale close to
         * mean solar time, UTC is occasionally corrected by an adjustment, or "leap",
         * of one second.
         */
        boost::system_time tAbsoluteTimeUtc = local_adj::utc_to_local(tAbsoluteTime);

        // Calculate the local-to-utc difference.
        boost::posix_time::time_duration tLocalUtcDiff = tAbsoluteTime - tAbsoluteTimeUtc;

        // Get only the seconds from the difference. These are the leap seconds.
        tAbsoluteTime += boost::posix_time::seconds(tLocalUtcDiff.seconds());

        bool done;
        boost::mutex m;
        boost::condition_variable cond;

        boost::unique_lock<boost::mutex> lk(m);
        while(!done)
        {
            if(!cond.timed_wait(lk,tAbsoluteTime))
            {
                done = true;
                std::cout << "timed out";
            }
        }
        return 1;
}

我测试过它有问题的，没有问题的机器，它的工作如预期两个，所以只要我保持它，因为我无法找到一个更好的解决方案。

I've tested it on problematic and non-problematic machines and it worked as expected on both, so I'm keeping it as long as I can't found a better solution.

感谢大家的帮助。

这篇关于升压TIMED_WAIT闰秒问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！