2012-06-05 3 views
13

Zunächst gehe ich davon aus, dass das Aufrufen einer Funktion von std :: chrono garantiert Thread-sicher ist (kein undefiniertes Verhalten oder Rassenbedingungen oder etwas Gefährliches, wenn es von verschiedenen Threads aufgerufen wird). Hab ich recht?Gibt es eine std :: chrono Thread-Sicherheitsgarantie auch bei Multicore-Kontexten?

Als nächstes, zum Beispiel on windows there is a well known problem related to multi-core processors, dass some implementations of time related systems to allow forcing a specific core to get any time information Kraft.

Was ich wissen möchte, ist:

  1. mit std :: Chrono, in der Norm, gibt es keine Garantie, die Art von Problem denken sollte nicht angezeigt werden?
  2. oder ist die Implementierung definiert
  3. oder gibt es eine explizite Abwesenheit der Garantie, die implizieren, dass unter Windows Sie immer Zeit immer aus dem gleichen Kern bekommen?
+1

Das KB Artikel ein Hardwareproblem beschreibt. Es hat nichts speziell mit Windows zu tun. Das gleiche Problem tritt bei * jedem * Betriebssystem auf, das diesen Hardware-Timer verwendet. Und nein, es gibt nichts im C++ - Standard, der sagt: "Diese Klasse darf sich schlecht verhalten, wenn Sie Ihren Code auf seltener defekter Hardware ausführen". – jalf

+0

Mein Verständnis ist, dass das Problem nur unter Windows auftritt? Wie auch immer, warum entfernst du deine Antwort? Auch das beantwortet nicht alle Punkte, die ich stelle. – Klaim

+0

Schauen Sie sich an, was der KB-Artikel sagt: "Das Verhalten dieses Betriebssystems ist von Entwurf. Die Anpassung des Leistungszählers ist erforderlich, wenn das Betriebssystem unzuverlässige Daten vom Chipsatz erhält.". Es kann auf jedem Betriebssystem auftreten.Microsoft dokumentiert es nur, weil die Leute es oft genug dort gefunden haben, um einen KB-Artikel zu rechtfertigen (teilweise weil Windows weit verbreitet ist und teilweise weil es weit verbreitet für Spiele verwendet wird, wo hochauflösende Timer häufiger verwendet werden) – jalf

Antwort

5

Ja, Aufrufe an some_clock::now() aus verschiedenen Threads sollten threadsicher sein.

In Bezug auf das spezifische Problem, das Sie mit QueryPerformanceCounter erwähnen, ist es nur, dass die Windows-API ein Hardwareproblem auf einigen Plattformen aufdeckt. Andere Betriebssysteme können dieses Hardwareproblem möglicherweise dem Benutzercode aussetzen. Wenn der Takt eine "stetige Uhr" ist, dann darf er niemals rückwärts gehen, wenn also zwei Lesevorgänge in demselben Thread stattfinden, darf der zweite niemals einen früheren Wert zurückgeben als der erste, auch wenn das Betriebssystem den Thread auf einen anderen Prozessor schaltet.

Für nicht stabile Uhren (wie zB std::chrono::system_clock auf vielen Systemen) gibt es keine Garantie dafür, da ein externer Agent die Uhr ohnehin beliebig ändern kann.

Mit my implementation of the C++11 thread library (einschließlich der std::chrono Zeug) die Implementierung sorgt dafür, dass die stationären Uhren tatsächlich stabil sind. Dies verursacht Kosten über einen rohen Aufruf hinaus an QueryPerformanceCounter, um die Synchronisierung sicherzustellen, aber pinnt den Thread nicht mehr an CPU 0 (was er früher getan hat). Ich würde erwarten, dass andere Implementierungen für dieses Problem auch Problemumgehungen haben.

Die Anforderungen für eine stete Uhr sind in 20.11.3 [time.clock.req] (C++ 11-Standard)

+0

Ich akzeptiere diese Antwort, weil es sagt, dass steady_clock niemals rückwärts gehen sollte, genau das muss ich am Ende wissen. Wenn Sie jedoch Referenzen zum Standard hinzufügen könnten, wäre das großartig. Außerdem bin ich dumm, dass ich dich nicht zuerst gefragt habe, du bist in der Boost-Mailingliste und ich bin mitten in deinem Buch ... XD – Klaim

+1

Die Anforderungen für eine stabile Uhr sind in 20.11.3 [time.clock. req] –

+0

Weiß jemand, ob std :: chrono :: steady_clock :: time_point "vernünftigerweise erwartet" ist, so gut wie eine atomare Variable zu sein, wenn ein vorheriger Wert mit einem neuen zurückgesetzt wird (während gleichzeitig von einem anderen Thread gelesen wird) – Ghita

-1

Ich glaube ehrlich, dass diese Frage vollständig durch die folgende Aussage beantwortet wird: Es gibt keine Garantie, dass eine Implementierung keine plattformspezifischen Fehler haben wird. Es soll alles perfekt funktionieren, aber manchmal tut es das aus irgendeinem Grund nicht. Niemand kann dir versprechen, dass es tun wird, was du willst, aber es soll funktionieren.

Verwandte Themen