Administrace komentářů

Jak se tomu postupně snažím porozumět, mám dojem, že je to naopak. Kompilátor nemá seznam funkcí, ke kterým se musí chovat speciálně. Má seznam s opačným významem.

Na tom seznamu jsou funkce, které zaručeně nikdy nemohou mít pozorovatelný vedlejší efekt. Mezi tyto „bezpečné“ funkce patří například putchar(), puts() a jim podobné. Všechny ostatní funkce jsou zpočátku implicitně „nebezpečné“. U těch, jejichž kód má kompilátor bezprostředně k dispozici v době překladu, se pokusí určit, zda je lze považovat za bezpečné. Ty, jejichž kód není k dispozici nebo u nichž analýza aliasů nedává stoprocentní záruky bezpečnosti, jsou i nadále považovány za nebezpečné.

Tedy zjednodušeně řečeno, pthread_mutex_lock() a moje_funkce_z_dynamické_knihovny() jsou z pohledu kompilátoru obě stejně nebezpečné a k oběma se musí přistupovat v rukavičkách, zejména pokud jde o paměťové operace kolem jejich volání.

Pokud lze pthread_mutex_lock() inlinovat, není to žádný problém. Obsahuje totiž kus asm volatile, který zcela zjevně dělá něco s pamětí. Tedy kompilátor může inlinovat, ale rozhodně si nedovolí příslušnou paměťovou bariéru zpřeházet s ostatními instrukcemi. A už vůbec si netroufne vynechat okolní čtení z paměti.

Nejjednodušším případem je funkce static void myFunction( void ) { puts( "Stupid kidding" ); }. Tu lze kompletně zanalyzovat, označit za bezpečnou a paměťové operace kolem jejího volání přehazovat či vynechávat jakkoliv dle libovůle.

Ještě bych rád uvedl jeden zajímavý případ: Co když standardní výstup vede na vstup jiného programu, který má s tím naším sdílenou paměť? Co když ten druhý program v reakci na zprávu zaslanou pomocí puts() zapíše něco do sdílené paměti? Co když zapisuje právě na místo, kde leží řídící proměnná cyklu volajícího puts()? Odpověď je jednoduchá: Výsledek něčeho takového je nedefinovaný, stejně jako jakýkoliv jiný nesynchronizovaný přístup ke sdíleným datům. O tom jsem se koneckonců (i když ne tak krkolomně) sám přesvědčil v mém pokusu níže.

Výše uvedený případ je podle mě (jen tak mimochodem) jedním z vzácných případů, kdy by se místo (náročné meziprocesové) synchronizace hodilo řídící proměnnou prostě označit (z pohledu obou procesů) jako volatile. Tím se samozřejmě nedosáhne ani synchronizace přístupů k proměnné ani atomicity změn. Pouze se zajistí viditelnost těch změn.

To všechno ale nic nemění na faktu, že tam, kde už používám (mutex | barrier | rwlock | mutex + condvar) nepotřebuji volatile vůbec.

Ale pořád nevím, jestli je tohle všechno pravda a jestli to už konečně chápu správně.