Unsynchronisiertheit des TSC auf mehreren CPUs

Testprogramm tscsynctest

• Ein Produzent (Thread) frägt die TSC ab und signalisiert dies einem Konsumenten mittels einer Conditionvariable.
• Der Consument (anderer Thread) vergleicht nach der Signalisierung das empfangene Ergebnis mit einer eigenen TSC-Abfrage nach dem Empfang der Signalisierung.
• Mit Hilfe der Linux-spezifischen Systemoperation sched_setaffinity wird in jedem Thread angewiesen, eine eigene CPU zu allokieren.

Erwartung: Bei synchronen TSC auf allen CPUs darf es nicht vorkommen, dass der Kosument eine kleinere Zeit liest, als der Produzent gesendet hat.

Sollte diese Erwartung nicht erfüllt sein, wird ein '#' auf stderr geschrieben.

Anschaulich kann man sich das als "Pseudo-Wurmloch" im simulierten Universum vorstellen, das kausale Ereignisse aus der Zukunft in der Vergangenheit eintreffen!

(Nebenbei dient dieses als Beispiel, wie man die direkte pthread-API sowie die Scheduler-CPU-Affinity-Aufrufe ohne Wrapper verwendet.)

Download tscana.tgz, Unterverzeichnis synctest

Ergebnisse

x86_64, Opensuse 11.1. auf ESXi

Es gibt Läufe von tscsynctest, bei denen die Erwartung nicht erfüllt ist ! (Andererseits ist die Erwartung auch oft erfüllt.)

Dies ist durchaus erstaunlich, da zusätzlich noch Effekte der Virtualisierung hinzukommen, so könnte ja zwei virtuelle CPUs vom selben physikalischen Prozessor realisiert sein könnten und die TSC Uhr trotzdem geteilt wird.

Andere Arbeiten

• Auch Counting on the time stamp counter von 2006 hat noch nie einen synchronen TSC beobachtet (1996-2006)