memoria condivisa - devo flushare?

[71104]

parlando sia di Linux che di Windows, se utilizzo un file mappato per creare una zona di memoria condivisa tra processi, oltre a dovermi sincronizzare con mutex e quant'altro per mantenere la consistenza dei dati condivisi devo anche flushare la cache del processore in un ambiente multicore? o ci pensa in qualche modo già l'architettura hardware in maniera a me trasparente?

per ragionare in termini pratici: mettiamo che sono su Windows e ho un file mappato creato come parte del file di swap (una pura area di memoria condivisa insomma); e mettiamo che nella zona di memoria condivisa ho una lista (e i link della lista sono espressi come offset anziché come puntatori perché la zona di memoria può essere mappata ad indirizzi diversi in processi diversi, ma vabbè). inoltre ho anche un mutex su cui un processo deve bloccarsi quando vuole aggiungere o togliere nodi; prima di rilasciare il mutex il processo deve anche assicurarsi che i cambiamenti siano andati in memoria fisica flushando la cache del core su cui ha lavorato?

[71104]

ah, ed inoltre dovrei dichiarare i nodi della lista come volatile per impedire al compilatore di ottimizzare cachandoli nei registri, giusto?

[cionci]

Originariamente inviato da 71104

prima di rilasciare il mutex il processo deve anche assicurarsi che i cambiamenti siano andati in memoria fisica flushando la cache del core su cui ha lavorato?

Che io sappia no. In u ambiente SMP ci sono algoritmi per la cache snoop delle altre CPU che dovrebbero evidenziare la presenza dal dato in cache...se il thread/processo invece termina il suo time slice, la cache viene automaticamente flushata e quindi le locazioni modificate vengono scritte in memoria.

[-fidel-]

Originariamente inviato da 71104

parlando sia di Linux che di Windows, se utilizzo un file mappato per creare una zona di memoria condivisa tra processi, oltre a dovermi sincronizzare con mutex e quant'altro per mantenere la consistenza dei dati condivisi devo anche flushare la cache del processore in un ambiente multicore? o ci pensa in qualche modo già l'architettura hardware in maniera a me trasparente?

Confermando quanto detto da cionci, sì, se ne occupa l'hardware / il kernel (almeno, ti parlo di kernel Linux, ma non credo che con Win Vista la situazione sia troppo diversa).
Comunque non afferro il problema...

[-fidel-]

Originariamente inviato da 71104

ah, ed inoltre dovrei dichiarare i nodi della lista come volatile per impedire al compilatore di ottimizzare cachandoli nei registri, giusto?

Se non vuoi che il compilatore faccia "ipotesi" su quelle variabili quindi fare cache o "predizioni" sui valori, sì.
Però, come prima, mi sa che mi sono perso qualcosa sul fine ultimo del tutto...

[cionci]

Il problema a cui si riferiva è che essendo i dati in cache non ancora scritti, un eventuale secondo processore avrebbe trovato dati non aggiornati in memoria centrale

[-fidel-]

Originariamente inviato da cionci

Il problema a cui si riferiva è che essendo i dati in cache non ancora scritti, un eventuale secondo processore avrebbe trovato dati non aggiornati in memoria centrale

Ah, beh ma se dovessimo preoccuparci di questo saremmo proprio a posto
Meglio che lavorino alla Intel/AMD

[71104]

Originariamente inviato da cionci

Il problema a cui si riferiva è che essendo i dati in cache non ancora scritti, un eventuale secondo processore avrebbe trovato dati non aggiornati in memoria centrale

esatto, e nel caso di una lista doppiamente linkata "dati non aggiornati" potrebbe voler dire "inconsistenti" (es. un nodo punta al successivo come successore, il quale però punta due nodi addietro come predecessore). senza contare che se il flush (che sia dei registri o della cache) avvenisse in un momento non ben definito in cui il mutex non è bloccato, altri processi di fatto osserverebbero dei cambiamenti in un momento in cui il mutex appunto non è bloccato da chi li ha fatti.

[71104]

cmq grazie cionci; non me ne devo preoccupare dunque, mi basta volatile.

[71104]

Originariamente inviato da -fidel-

Ah, beh ma se dovessimo preoccuparci di questo saremmo proprio a posto

però intanto di dichiarare i nodi come volatili me ne sono dovuto preoccupare
le cose non sono del tutto trasparenti anche se in realtà in questo caso sarebbe un problema del compilatore e non dell'architettura.

[cionci]

Originariamente inviato da 71104

altri processi di fatto osserverebbero dei cambiamenti in un momento in cui il mutex appunto non è bloccato da chi li ha fatti.

Se succede significa che hai gestito male la mutua esclusione...quando rilasci la mutua esclusione i dati devono essere consistenti.

[-fidel-]

Originariamente inviato da 71104

però intanto di dichiarare i nodi come volatili me ne sono dovuto preoccupare

Perchè? Per lo meno, "volatile" la si usa normalmente in ambiente multithread/multiprocesso (affinche il compilatore eviti race conditions al posto tuo ) ma in ambiente multiprocessore il tutto è lasciato all'hardware.
Fai bene a dichiarare i nodi come "volatile" ma non a causa un ambiente multiprocessore, ma di multithreading (comunque se usi una sezione critica fatta bene puoi anche evitare, non se4rve a nulla visto che da quel punto di vista non hai race conditions).

[71104]

Originariamente inviato da cionci

Se succede significa che hai gestito male la mutua esclusione...quando rilasci la mutua esclusione i dati devono essere consistenti.

non è detto che il flush avvenga prima del rilascio del mutex e non penso che sia possibile assumere che il flush di una locazione (ad es. quella di uno dei due link del nodo) implichi il flush di un'altra (quella dell'altro link). sequenza cronologica delle operazioni:
1) i due link vengono scritti nei registri; da questo momento il mutex per quanto ne so io (che non sono a conoscenza delle ottimizzazioni operate dal compilatore e dell'uso che fa dei registri) può essere rilasciato
2) il link al nodo precedente viene messo in memoria fisica
3) viene rilasciato il mutex
4) un thread che gira su un altro processore blocca il mutex e vede i dati inconsistenti
5) l'altro link viene messo in memoria fisica

quindi ciò che mi preme è che prima del rilascio del mutex tutto sia completamente flushato. visto che l'hardware mi rende la cache trasparente, io mi preoccupo solo dei registri, quindi uso volatile.

[cionci]

Mi sembra che tu ti stia facendo problemi inutili...stai programmando ad alto livello...a tutto il resto ci pensa l'hardware e il compilatore...

- acquisisci la mutex
- lavori sulla memoria condivisa
- rilasci la mutex quando la memoria condivisa è in uno stato consistente

Basta, te non devi pensare ad altro...se fai altre supposizioni sei fuori strada perché c'è il rischio che il tuo codice non funzioni su tutte le architetture

[recoil]

Originariamente inviato da cionci

Mi sembra che tu ti stia facendo problemi inutili...stai programmando ad alto livello...a tutto il resto ci pensa l'hardware e il compilatore...

- acquisisci la mutex
- lavori sulla memoria condivisa
- rilasci la mutex quando la memoria condivisa è in uno stato consistente

Basta, te non devi pensare ad altro...se fai altre supposizioni sei fuori strada perché c'è il rischio che il tuo codice non funzioni su tutte le architetture

esattamente

[71104]

se il problema è reale io ci penso

anche perché sennò il prof mi chiede come mai non ho usato volatile per dichiarare dei dati usati da thread diversi, che quello è pignolo è

[71104]

e poi programmo ad alto livello per modo di dire: sto usando il C...
pensate che devo scrivere #ifndef __MACRO__, #define __MACRO__ all'inizio di ogni header, e ovviamente l'#endif alla fine

[71104]

Originariamente inviato da 71104

e poi programmo ad alto livello per modo di dire: sto usando il C...

a-ehm, ci tengo a precisare che questa frase NON voleva significare "sto usando il CULO "
no perché poteva essere

[recoil]

Originariamente inviato da 71104

e poi programmo ad alto livello per modo di dire: sto usando il C...
pensate che devo scrivere #ifndef __MACRO__, #define __MACRO__ all'inizio di ogni header, e ovviamente l'#endif alla fine

è una buonissima abitudine

[71104]

Originariamente inviato da recoil

è una buonissima abitudine

si, solo che è un'abitudine trogloditica, come il resto di quel linguaggio
sono abituato al sistema di packaging di Java

e poi meno male che uso C99, sennò mi toccava pure dichiarare tutte le variabili all'inizio e dovevo rinunciare a const e alle variabili dichiarate nelle intestazioni dei for.