Administrace komentářů

Ještě tu mám dva zdrojáky, ve kterých funkce volaná v odděleném vlákně mění lokální proměnnou jiného vlákna, na které závisí další běh programu.

Napřed bez synchronizačních primitiv:

#include <unistd.h>
#include <stdio.h>
#include <pthread.h>

static void * setzero( void * param ) {
        *( (int *) param ) = 0;
        return NULL;
}

int main( void ) {
        int local = 1;
        pthread_t thread;

        pthread_create( &thread, NULL, setzero, &local );
        while ( local );
        pthread_join( thread, NULL );
        puts( "The thread has finished." );
        return 0;
}

Tohle dopadne zruba takto:

Chování GCC je zcela podle předpokladů. Proměnná není není chráněna primitivem a zároveň není volatile, tudíž při zapnutí optimalizace původní záměr samozřejmě selže. Proč ale kód z ICC nezamrzne? Je to absurdní, ale ICC celý while cyklus odstraní!

Naskýtá se otázka: Že by snad ICC analyzoval vytváření vláken a zjistil, co se může s tou proměnnou stát? Ne, to se neděje. Je snadné to dokázat: Když ve funkci setzero() přiřadíme místo nuly například dvojku, while cyklus bude odstraněn taky. A to je naprosto špatně. Je to bug v kompilátoru, nebo jen v mé hlavě? V assembleru je přesně toto:

        pushl     %eax                                          #14.42
        pushl     $setzero                                      #14.42
        pushl     $0                                            #14.42
        pushl     %edx                                          #14.42
        call      pthread_create                                #14.2
                                # LOE ebx esi edi
..B1.2:                         # Preds ..B1.7
        pushl     $0                                            #16.24
        pushl     32(%esp)                                      #16.24
        call      pthread_join                                  #16.2

Teď druhý kousek, tentokrát se synchronizačními primitivy.

#include <unistd.h>
#include <stdio.h>
#include <pthread.h>

static pthread_mutex_t mutex;
static pthread_cond_t cond;

static void * setzero( void * param ) {
        *( (int *) param ) = 0;
        pthread_cond_signal( &cond );
        return NULL;
}

int main( void ) {
        int local = 1;
        pthread_t thread;

        pthread_mutex_init( &mutex, NULL );
        pthread_cond_init( &cond, NULL );
        pthread_create( &thread, NULL, setzero, &local );

        pthread_mutex_lock( &mutex );
        while ( local ) pthread_cond_wait( &cond, &mutex );
        pthread_mutex_unlock( &mutex );

        pthread_join( thread, NULL );
        puts( "The thread has finished." );
        pthread_cond_destroy( &cond );
        pthread_mutex_destroy( &mutex );
        return 0;
}

Funkce setzero() vůbec nezamyká mutex, když signalizuje změnu podmínkové proměnné. Nicméně podle manuálové stránky je něco takového povoleno. Vše funguje zcela korektně pro všechny úrovně optimalizace u GCC i ICC. I z pohledu assembleru je vše v pořádku, lokální promměná v cyklu v main() se skutečně vždy načte znovu.

Tady je fragment assembleru z kompilátoru Intel při -O3, který odpovídá té smyčce v main():

..B1.5:                         # Preds ..B1.20 ..B1.19
        movl      4(%esp), %eax                                 #22.10
        testl     %eax, %eax                                    #22.10
        je        ..B1.10       # Prob 10%                      #22.10
                                # LOE ebx esi edi
..B1.7:                         # Preds ..B1.5
        pushl     $mutex.0                                      #22.44
        pushl     $cond.0                                       #22.44
        call      pthread_cond_wait                             #22.18
                                # LOE ebx esi edi
..B1.20:                        # Preds ..B1.7
        addl      $8, %esp                                      #22.18
        jmp       ..B1.5        # Prob 100%                     #22.18
                                # LOE ebx esi edi

Dokonce ani lokální proměnná tedy nemusí být volatile, když se používá jako podmínková. V případě inlinování pthread_cond_wait() by to dopadlo stejně, protože tato funkce musí za všech okolností obsahovat speciální instrukce a tudíž i blok asm volatile s kouzelným slovem "memory" v seznamu změněných registrů.

Začínám být čím dál pevněji přesvědčen, že podmínková proměnná nikdy nemusí být volatile a že toto chování překladačů se ani v budoucnu nemůže změnit.