Administrace komentářů

Tak, celou noc jsem pročítal assembler, který vznikal z různých pokusných programů. Už začínám tušit, jak moc jsem se mýlil a jak špatně jsem pochopil výsledky mého výše uvedeného pokusu. Vše dále popsané jsem pro jistotu zkoušel pouze s -O3.

Nic se nepřesunulo přes nanosleep(). Zdání něčeho takového vzniklo prostě takto:

1. Kompilátor zjistil, že v celém programu jen main() přiřazuje do proměnné flag a přiřazuje tam konstantu.
2. Proto z proměnné flag udělal konstantu s (poslední) hodnotou 0.
3. Proto právě ta vlákna, která končila podezřele brzy, žádný spinlock v sobě neměla. Optimalizace ho zrušila.

Další dvě důležité poznámky:

1. Stačilo do kterékoliv další funkce přidat přiřazení do flag a najednou všechny funkce poctivě flag četly. Sice pouze jednou, ale přece. (V důsledku toho pak vlákna neskončila vůbec, zůstala ve spinlocku.)
2. Stačilo do cyklu přidat volání nějaké nedefinované funkce a proměnná flag se pak už četla znovu v každém cyklu. Zajímavé je, že například puts() a putchar() čtení v cyklu nezpůsobily, zatímco pthread_yield(), pthread_mutex_lock() nebo something_undefined() ano. Kompilátor tedy skutečně má nějaký interní seznam „bezpečných“ funkcí a všechny ostatní považuje implicitně za „nebezpečné“.

Teď už asi konečně chápu, proč ta synchronizační primitiva fungují i bez volatile. Může se k nim přistupovat pouze dvěma způsoby:

• Pomocí funkcí, které jsou z dynamicky linkované knihovny. Takové funkce kompilátor neinlinuje a dokonce se zdá, že jejich volání je v assembleru vždy přesně na požadovaném místě. Svůj hloupý omyl s pořadím nanosleep() jsem si už ujasnil a jinou záměnu pořadí jsem zatím nepozoroval.
• Pomocí funkcí, které lze inlinovat. Takové funkce ovšem vždy obsahují nějaký vhodný blok asm volatile s náležitými synchronizačními instrukcemi. Tudíž ani v tomto případě není důvod obávat se změny pořadí.

Můj celkový závěr (po důkladné revizi a úspěšném pochopení výsledků mého pokusu) tedy zní: Sinuhet měl pravdu a já jsem se mýlil. Skutečně není třeba používat volatile současně se synchronizačními primitivy.

Děkuji všem za věcnou a zajímavou diskusi a zejména Sinuhetovi za objasnění celé záležitosti. Pro mě z toho plyne poučení, že jsem si měl napřed přečíst assembler a teprve potom dělat závěry ohledně výstupu mého pokusného programu.