Ottimizzazione del compilatore, thread sicuro?

Question

Ho una domanda riguardante le ottimizzazioni che il compilatore può potenzialmente fare.

Il codice qui sotto parlerà da sé (questo è un esempio):

typedef struct test 
{ 
    short i; 
}    s_test; 

int function1(char *bin) 
{ 
    s_test foo; 

    lock(gmutex); 
    foo.i = *(int*)bin * 8; 
    unlock(gmutex); 

    sleep(5); 
    // 
    // Here anything can happen to *bin in another thread 
    // an inline example here could be: *(volatile int *)bin = 42; 
    // 

    int b = foo.i + sizeof(char*); 

    return (b > 1000); 
} 

Potrebbe il compilatore mai sostituire le ultime righe con

return ((*(int*)bin * 8 + sizeof(char*)) > 1000); 

Non sembra essere il caso con -O2 o -O3 con gcc 4.4 ma potrebbe essere il caso con altri compilatori e con altre bandiere di compilazione?

Answer 1

Non penso che il compilatore eseguirà un tale tipo di ottimizzazione.

questa è la funzione, il compilatore non può assumere che il valore indicato da bin verrà modificato nella funzione di sblocco o meno.

per esempio, forse bin proviene da un globo. Quindi l'ottimizzazione per bin non può attraversare la chiamata di funzione.

Answer 2

Il tuo esempio è inutilmente complicato perché stai leggendo bin attraverso un tipo diverso da quello dichiarato. Le regole di aliasing sono piuttosto complicate, char è addirittura speciale, non vorrei commentare in merito.

Supponendo che la dichiarazione sia int* bin (e quindi non si debba eseguire il cast del puntatore) un compilatore non avrebbe il diritto di riordinare le istruzioni tra le chiamate di funzione, formando i cosiddetti punti di sequenza. Il valore di *bin prima e dopo la chiamata a unlock potrebbe essere diverso, pertanto ha per caricare il valore dopo la chiamata.

Edit: come notato da Slartibartfast, per questo argomento è essenziale che unlock è (o contiene) una chiamata di funzione e non è solo una macro che si risolve in una sequenza di operazioni dal compilatore.

Answer 3

Come ho detto nella risposta diretta: il tuo mutex non protegge nulla IMHO. L'array di caratteri in cui * bin si inserisce può essere modificato durante l'accesso int in modo che, a seconda della macchina, non si ottenga una vista coerente sulla memoria a cui si desidera accedere. Torna alla tua domanda: un compilatore non trasformerà il codice sorgente nella sequenza che hai immaginato, ma potrebbe benissimo produrre un linguaggio macchina che in effetti si comporterà come il tuo codice sorgente. Se è in grado di ispezionare le funzioni blocca, sblocca e dorme (che sembrano essere comunque macro) e può dedurre che non vi è alcun effetto collaterale sulle posizioni di memoria coinvolte E non vi è alcun significato definito dall'implementazione per le chiamate ad es. sleep() che renderebbe non valido ("memorizzato nella cache", sebbene lo standard non usi questo termine) valori non validi, allora ha il diritto di produrre una sequenza di istruzioni come quella che hai dato. C (fino a C99) è intrinsecamente a thread singolo e il compilatore può impiegare qualsiasi strategia di ottimizzazione che vuole purché il codice si comporti come se fosse eseguito sulla macchina ipotetica ideale. I punti di sequenza che Jens ha menzionato non influiscono sulla correttezza in condizioni di thread singolo: il compilatore potrebbe contenere foo in un registro durante l'intera funzione o potrebbe anche alias foo.i con la posizione di memoria puntata da * bin, quindi questo codice è intrinsecamente pericoloso (anche se penso che non mostrerà questo comportamento sulla maggior parte dei compilatori).