Administrace komentářů

Pro názornost:

pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
volatile int x = 0;

// 1. vlákno
pthread_mutex_lock(&mutex);         // zamkne mutex
while (x == 0)                      // při každém průchodu čtu novou hodnotu x (mohlo ji modifikovat jiné vlákno)
{
  pthread_cond_wait(&cond, &mutex); // odemkne mutex (umožní tak modifikaci x), čeká na pthread_cond_signal, zamkne mutex
}
pthread_mutex_unlock(&mutex);       // odemkne mutex

// 2. vlákno
pthread_mutex_lock(&mutex);         // zamkne mutex
x = 1
pthread_cond_signal(&cond);         // způsobí probuzení pthread_cond_wait v 1. vlákně
pthread_mutex_unlock(&mutex);       // odemkne mutex a umožní tak 1. vláknu si ho opět přivlastnit ve funkci pthread_cond_wait

Pokud by proměnná x nebyla volatile, měl by překladač plné právo předpokádat, že hodnota x se nemůže sama od sebe změnit a může ji tedy beztrestně uložit do registru. Napadlo mě jen, že díky tomu, že v cyklu je ještě obsaženo volání funkce pthread_cond_wait o níž neví, zda nemodifikuje obsah x, tak se překladač nemůže spoléhat, že x zůstane zachované a žádnou optimalizaci ohledně x si nemůže dovolit. Avšak v případě, že pthread_cond_wait je inline funkce a nevolá žádné další non-inline funkce, mohl by kompilátor vědět, zda se hodnota x mění, či ne a naznačenou optimalizaci by mohl provést. Přenositelný kód by neměl dělat žádné předpoklady o funkci pthread_cond_wait (inline/non-inline), a proto je užití volatile jistě opodstatněné, i když s velkou pravděpodobností jeho absence nezpůsobí žádné problémy.