Administrace komentářů

Je zjevné, že kompilátor Intel někdy přesouvá přiřazení globální proměnné směrem nahoru i přes několik volání funkcí.

Nicméně GCC jsem hodně křivdil a byla to moje chyba. V tom pozměněném zdrojáku je inkrementace té proměnné. Tedy jde o naprosto normální race condition, která může dopadnout pokaždé jinak a samozřejmě závisí na zvolené optimalizaci. Tedy za humbuk kolem vlákna T3 se moc omlouvám. Tak to dopadá, když člověk dělá zoufalé pokusy pozdě v noci.

Je možné, ne-li pravděpodobné, že GCC přiřazení do proměnné flag buď přesune směrem dolů, nebo zcela vynechá, protože flag už funkce main() po přiřazení nikde nečte. FLAG je volatile, tedy se vždy správně přiřadí.

Podivné chování vláken při některých optimalizacích se ovšem nedá vysvětlit jinak než tím, že kompilátor přesouvá přiřazení globální proměnné přes několik volání funkcí. Fakt je tohle korektní? Kde mám vzít jistotu, že to přiřazení nepřesune přes pthread_mutex_lock() a pthread_mutex_unlock()???

Některé výsledky mého pokusu možná přece jen budou mít racionální vysvětlení a už mě to tolik neděsí. Nicméně pořád jsem z toho dost (nepříjemně) překvapený. Svět prostě nefunguje tak, jak jsem si dlouhou dobu představoval. Že jsem zatím při programování na žádnou z těchto ošklivých situací nenarazil, to je prostě obrovská šťastná náhoda. Jinak si to neumím vysvětlit.

Například provedu-li tohle,

pthread_mutex_lock( &queueMutex );
++itemsAvailable;
pthread_cond_signal( &queueCond );
pthread_mutex_unlock( &queueMutex );

kde vezmu jistotu, že kompilátor neprovede inkrementaci někdy před pthread_mutex_lock() nebo po pthread_mutex_unlock()? Obojí by mělo fatální následky. Čím přesně je zaručeno, že se to nestane? Jinými slovy, čím přesně se ty dvě zmíněné funkce liší od nanosleep(), pthread_ceate(), puts() a dalších, které kompilátor klidně zpřehází a přesune přes ně přiřazení?