Administrace komentářů

Frknu to sem k vam, ale tyka se to i ostatnich volatilistu.

Pratele, mne se zda, ze nejen ze neznate standard, ale ani se na chvili nezamyslite nad tim, kde bychom s vasimi predstavami dovedenymi do dusledku skoncili. Prekladac muze optimalizovat kod, ale obecne jen do te miry, aby nezmenil pozorovatelne chovani programu. Standard predpoklada, ze vsechny objekty lezi kdesi v pameti, jedne pro cely program, a prekladac muze optimalizovat pristup k nim tim, ze si je natahne do registru procesoru, nicmene toto muze udelat pouze tehdy, pokud je presvedceny, ze je nikdo mezitim v pameti neprepsal. Vezmneme si trivialni priklad:

void clobber();

bool test(int* a)
{
	*a = 3;
	clobber();

	if( *a == 3 )
		return true;
	else
		return false;
}

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.

Tohle plati obecne pro vsechny funkce a pro pthread_mutex_lock, pthread_mutex_unlock a pthread_cond_wait obzvlast, nebot za jejich "behu" muze dojit ke zmene v pameti uz z definice. 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. Dokud si timto nebude jist, tak vzdy bude muset znovu natahnout hodnotu z pameti, jinak se nechova podle standardu.

Abych to shrnul a asi po treti zopakoval sam sabe. 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. 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.