Administrace komentářů

Pratele, mne se zda, ze nejen ze neznate standard, ...

V mém případě je to naprostá pravda. Tu šílenou bichli jsem skutečně nečetl.

Po zavolani fce clobber() musi prekladac znovu nacist hodnotu *a z pameti, nemuze vedet, jestli se mezitim nezmenila, protoze nezna definici clobber() a nevi, co presne dela. Takze zaverecny if nemuze odoptimalizovat.

Vsuktu? Platí tohle i v případě, že knihovnu s funkcí clobber() linkuji staticky? Co když funkce clobber() neobsahuje vůbec žádný mov se zápisem do paměti (na Intelu)? Co když neobsahuje žádný store (na nějakém RISCu)? Klidně může existovat funkce, která vůbec nikam do paměti nepíše. (Kromě manipulace se zásobníkem, ale na tu opravdu nikdo jiný paralelně nesahá.) Opravdu si něčeho takového kompilátor nesmí všímat? Ani v budoucnu?

Nejaky hypoteticky prekladac budoucnosti by teoreticky tuto optimalizaci mohl provest, ale jen pokud by zanalyzoval cely program a dosel k zaveru, ze zadne jine vlakno a ani nikdo jiny nebude v prubehu vykonavani fce pthread_cond_wait() menit hodnotu itemsAvailable.

Žádný překladač se určitě nepustí do tohoto algoritmicky neřešitelného problému. Nicméně pořád mi připadá v zásadě správné tu proměnnou označit jako volatile...

Klicove slovo volatile je zcela zbytecne, protoze to oc vam jde, totiz natahnuti hodnoty promene z pameti po pripadnem probuzeni, zaruci samo volani funkci kolem mutexu.

Možná. Například klíčové slovo const před deklarací pointerů je taktéž na spoustě míst (na první pohled) zbytečné, nicméně chrání programátora před budoucími ošklivými chybami. Říká „pozor, s těmito daty si nemůžeš hrát, ta ještě bude někdo potřebovat“. A volatile zase říká „pozor, s těmihle daty si občas paralelně hraje někdo jiný“. Že kompilátor možný problém postřehne a že nebude optimalizovat přístup do paměti přes volání funkcí, není z pohledu logiky celé věci až tak relevantní.

Deklaraci volatile akorat svuj program zpomalujete (potencialne docela hodne, zalezi jak casto s takovou promennou pracujete), protoze prekladac nutite nacitat/zapisovat promennou z/do pameti vzdy, i kdyz nehrozi, ze by ji nekdo jiny zmenil.

Zpomaluji? Pokud se ta proměnná čte i zapisuje vždy pouze pod (jedním a tím samým) mutexem a pokud mezi každými dvěma přísupy k té proměnné leží alespoň jedno volání funkce (třeba pthread_cond_wait(), když nic jiného), měla by být „rychlost“ programu s volatile i bez volatile srovnatelná. Nebo jsem něco přehlédl?

Velmi striktně vzato, jediné místo, kde je volatile skutečně bezpodmínečně potřeba, je spinlock. (Ten samozřejmě v userspace nemá co dělat, leda snad v implicitní podobě, kterou zajišťuje adaptivní mutex.) Nicméně stále mám (možná mylný) dojem, že použití volatile u podmínkové proměnné je tak nějak „logicky správné“. Navíc (jak už jsem poznamenal) skutečně nevidím žádné nevýhody stran efektivity. (Ale můžu se mýlit, což se mi stává často.)