Boost timed_wait Schaltsekunden-problem

Ich bin mit dem timed_wait aus der boost C++ library und ich bin immer ein problem mit den Schaltsekunden.

Hier ist ein quick-test:

#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;
}

Den timed_wait Funktion zurückgibt 24 Sekunden früher als es sein sollte. 24 Sekunden wird die aktuelle Anzahl der Schaltsekunden in UTC.

So, boost ist weit verbreitet, aber ich konnte nicht finden alle Informationen über dieses Besondere problem. Hat sonst noch jemand dieses problem erlebt? Was sind die möglichen Ursachen und Lösungen?

Hinweise: ich bin mit boost 1.38 auf einem linux-system. Ich habe gehört, dass dieses problem geschieht nicht auf MacOS.

UPDATE: EIN wenig mehr info: Dies passiert auf 2 redhat Maschinen mit kernel 2.6.9. Ich habe ausgeführt, den gleichen code auf einer ubuntu-Maschine mit dem kernel 2.6.30 und der timer verhält sich wie erwartet.

So, was ich denke ist, dass dies ist wahrscheinlich verursacht durch das Betriebssystem oder durch einige mis-Konfiguration auf der redhat Maschinen.

Habe ich codiert umgehen, stellt die Zeit auf UTC und bekommen als der Unterschied von dieser Anpassung und hinzufügen der ursprünglichen Zeit. Diese seens wie eine schlechte Idee zu mir, weil, wenn dieser code ausgeführt wird, auf einen Rechner ohne dieses problem, es könnte sein, 24s VOR. Immer noch konnte den Grund nicht finden für diese.

Ich verstehe es nicht. Sie sind die Einstellung timeout-Zeit von 0,5 Sekunden in die Zukunft, aber es ist das timing 24 Sekunden zu früh? Etwas nicht auf.
Dies ist nur ein Beispiel aus der Dokumentation. Ich werde es ändern, um besser reflektieren zu meinem Fall.
Jetzt, da wir festgestellt haben, dass dein Beispiel-code ist nichts, wie Ihre tatsächliche Anwendung, habe ich noch eine Frage: sind Sie mit einer aktuellen Zeit plus offset wie im Beispiel), oder sind Sie der Dekodierung einer bestimmten Zeit in einem boost::system_time?
Mein code ist genau, wie im Beispiel, deswegen habe ich es hier gepostet. Der einzige Unterschied ist, dass die Millisekunden offset die Eingabe eines Benutzers und, dass mein code mit Kommentaren 🙂
Umm, Nein ist es nicht. Die aktuelle TAI-UTC-Versatz beträgt 34 Sekunden. Sie sind offenbar stecken 1988: maia.usno.navy.mil/ser7/tai-utc.dat
wir nur Sorge um die Sekunden nach dem Beginn der Epoche (1970).
Dein Beispiel funktioniert bei mir mit Boost-1.41 auf Ubuntu 9.10.
Wie sind Sie auf der Anmeldung Ihre timer-Ereignisse? Vielleicht ist das problem mit Ihrem logger? Versuchen Sie den Druck direkt auf der standard-Ausgabe aus und Messen Sie mit Ihrer Uhr in Echtzeit.
Nur eine Idee... sind Sie läuft ein NTP-daemon auf dieser Maschine?

InformationsquelleAutor Isac | 2010-05-06

boost c++

2

Auf einem Linux-system, das system-clock folgt dem POSIX-standard, die Mandate, die
Schaltsekunden werden NICHT beachtet! Wenn du anders zu erwarten, das ist wahrscheinlich die Quelle der Diskrepanz, die Sie sehen. Dieses Dokument hat eine tolle Erklärung, wie die UTC bezieht sich auf anderen Zeitskalen, und die Probleme, die wahrscheinlich auftreten, wenn man setzt auf das Betriebssystem das Konzept der Zeitmessung.
- So, die Lösung zum hinzufügen von Schaltsekunden, wenn das OS ist linux? Gibt es nicht eine OS unabhängige Lösung? Heute ist mein Ziel-OS ist linux, aber es könnte sich ändern, eines Tages...
- Was ich nicht verstehe ist, warum gibt es diese 24s Unterschied, ob die get_system_time Anrufe auf der gleichen Maschine? Tut timed_wait eine andere Funktion, um die Zeit? Ich habe gelesen, die boost-Dokumentation, und Sie sagen, dass seit 1.36 verwenden Sie die time_and_date Klassen.
- Es sind keine Betriebssysteme, die ich kenne, wo die Systemuhr Hinsicht UTC-Schaltsekunden. Doch Sie beschreiben eine 24s-offset, die gleich der Anzahl der Schaltsekunden eingeführt, die seit der Unix-Epoche. Also ich habe auf der echo-Mark Lösegeld Kommentare: Sie müssen uns sagen, wie Sie sind zur Erfassung dieses 24s Unterschied, denn das ist nicht ersichtlich aus dem code, den Sie gepostet haben.
- Ich habe die Messung wie diese: Erste Methode: die überprüfung der Protokolle und der zu sehen war der timer feuern 24s früher. Zweite Methode: der Einstellung des Timers, um 24s oder niedriger und Sie sehen sofort Feuer. Mache ich falsch?
- Lewis: Tatsächlich, es sind schon 25 Schaltsekunden seit 1970. Nicht vergessen, die im Januar 2009.
- Also wenn der timer abläuft, und Sie drucken Sie sowohl den angeforderten abs_time timeout und dann aktuelle Zeit, sagst du, dass Sie dich auf den Weg, um 24 Sekunden?
- Nun, das würde passieren, innen timed_wait (, die andere Funktionen aufrufen, das zu tun), so weiß ich nicht, wer ist das hinzufügen oder entfernen von Sekunden. Meine Vermutung ist, dass diese Art der Prüfung ist Links, um das OS und das OS ist mit einer anderen Zeit get_system_time.
- Ich glaube nicht, dass wir gehen, um viel voran, bis Sie nach dem eigentlichen code...etwas in sich geschlossenes und komplett genug, dass wir das problem reproduzieren können Sie mit. Ansonsten sind wir einfach nur spielen raten spielen. Der Teufel steckt im Detail!
- Das problem passiert, mit genau diesem code auf einer redhat-Maschine mit kernel 2.6.9. Ich habe ausgeführt, der code auf einem ubuntu-Rechner mit 2.6.30 kernel und das problem ist nicht passiert. So, der code ist! Das problem ist möglicherweise nicht der code (es kann sein, ein kernel-level-problem oder ein problem mit der Konfiguration).
- Was du gepostet hast ist nicht komplett genug, um selbst zu kompilieren, also ist es nicht wirklich "genau diesem code". Aber Ihr und Emile Cormier ' s Beobachtungen, dass es richtig funktioniert auf einer anderen Maschine sind wichtig...möchten Sie vielleicht zu aktualisieren Sie Ihre Frage mit den zusätzlichen Informationen. Vielleicht ist es nicht eine UTC-versus POSIX-Zeit-Problem, nachdem alle, in dem Fall werde ich das löschen meiner Antwort.
- Ich wusste nur, dass. Ich werde mein test-code als auch.
InformationsquelleAutor Jim Lewis
1

Ist es möglich, dass getan wird immer gesetzt, vorzeitig beenden und eine vermeidbare wakeup verursacht die Schleife zu beenden, früher als Sie erwartet haben?
- Das klingt nach einem plausiblen Szenario, angesichts der Informationen, die wir bisher haben.
- Das würde nicht dazu führen das timer-Feuer 24s früher konsequent.
InformationsquelleAutor Mark B

Ok, hier ist was ich getan habe. Es ist ein workaround und ich bin nicht glücklich mit, aber es war das beste, das ich kommen konnte mit:

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;
}

Ich habe es getestet auf problematische und nicht-problematische Maschinen und es funktioniert wie erwartet, auf beiden, also ich bin es zu halten, solange ich nicht eine bessere Lösung gefunden.

Danke Euch allen für Eure Hilfe.

InformationsquelleAutor Isac

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.