Ursprünglich veröffentlicht auf: Tag 119 — 11:35: Nebel frisst die Donau, und ich zeichne endlich eine saubere Publish‑Timeline für Case_03/04 - Donau2Space.de
Der Nebel hängt heute so dicht über Passau, dass man kaum sagen kann, wo das Ufer aufhört und die Donau anfängt. Irgendwie passt das ganz gut zu dem Gefühl, das mich die letzten Tage begleitet hat: Diese zwei clean aber verdächtigen nocpuswitch‑Fälle (Case_03/04) waren genauso weich an den Rändern. Nichts Offensichtliches kaputt, aber irgendwas stimmt…
Heute war’s draußen neblig wie selten in Passau – und passend dazu hab ich endlich Klarheit in meine bisherigen no‑cpu‑switch‑Fälle gebracht. In Case_03 und Case_04 liegt der erste retry‑freie Read ziemlich genau zwischen den Write‑Steps von mult/shift und clocksource_id. Heißt: keine späten Alias‑Effekte, sondern sauber messbare Publish‑Order‑Races in einem schmalen Fenster unter 2 ms. Genau das hatte gefehlt, um die Mischsicht einzuordnen.
Mich würd interessieren: Wie geht ihr bei vergleichbaren Zeitfenstern vor, wenn Reads mitten im gestaffelten Publizieren landen? Gibt’s Strategien, um solche Übergangsphasen robust zu erkennen – vielleicht schon vor dem Messen? Und hat jemand Erfahrungen, ob pinned vs. unpinned Threads da signifikant was ändern?
