2010-07-13 13 views
6

un'occhiata a questo codice:Più thread: devo bloccare la lettura dei dati?

int data=5; 

void Thread1() 
{ 
    if(data==5) 
    { 
     //nothing 
    } 
} 

void Thread2() 
{ 
    if(data==2) 
    { 
     //nothing 
    } 
} 

in questo caso, ho bisogno di usare EnterCriticalSection/MutexLock prima, se (i dati == ..)?

+0

Nel tuo caso, No non hai bisogno di MutexLock. – Siddiqui

risposta

6

Se si stanno solo leggendo i dati, non è necessario alcun blocco.

Se si scrivono i dati E ci si preoccupa della lettura dei dati dell'ordine, quindi è necessario utilizzare CS per assicurarsi che l'ordine sia corretto. (Notare che se l'oggetto ha uno stato più complesso che non viene aggiornato in un'operazione atomica, potrebbe interessarsi di più all'ordinamento di letture/scritture).

+0

Se non ti interessa l'ordine, vorresti comunque cambiare la variabile in volatile, no? – Inverse

+0

L'utilizzo di volatile dipende dall'architettura del compilatore in ciò che significa in termini di multi-threading. Leggi la documentazione appropriata. –

1

Se nulla cambia i dati, quindi sulla maggior parte delle architetture, no no. Ma se mai nulla cambia i dati, il codice non ha senso.

+0

Questo è quello che stavo pensando. – GManNickG

+6

È molto utile inizializzare alcuni globali prima di generare eventuali thread aggiuntivi e da quel punto sui dati viene condivisa la lettura ma mai più scritta. –

0

Se il tuo esempio deve essere già completo allora no, non devi bloccare o gestire alcuna sezione critica poiché non stai modificando nulla.

Ma tu esempio, così com'è, è solo inutile ..

Non è necessario per gestire la concorrenza quando ci sono le discussioni che sono solo la lettura dei dati semplici (le cose sono diverse su strutture dati iterabili), ma questo è utile solo quando hai dati statici che non devono essere modificati. Non appena aggiungi uno scrittore, devi assicurarti che quando scrive nessuno stia leggendo, ma tutti saranno comunque in grado di leggere contemporaneamente ad altri lettori se nessuno scrittore sta facendo il suo lavoro.

0

Non è necessario bloccare quando non si modifica la memoria condivisa, ma il tuo esempio sarebbe abbastanza inutile da quando si inizializza data, si controlla il suo valore, ma non lo si modifica mai ... il secondo thread è sarà completamente inutile. Modifica la variabile data ovunque?

+0

si sta solo riducendo il mio codice, ho il file .ini che viene letto e imposta i dati prima dell'avvio dei thread, ho bisogno di accedere a tali informazioni da più thread in seguito, senza modificarlo :) non è inutile, l'applicazione è molto grande :)) – Tenev

+0

@tenev, non sto cercando di dire che quello che stai facendo è inutile, ma l'esempio che ci hai fornito implica che il secondo thread non farà nulla perché "data" è SEMPRE 5 ... – Kiril

1

Se i dati vengono modificati da un thread diverso, è necessario un recinto di memoria durante la lettura per garantire la coerenza. Un blocco è un modo per ottenere una barriera di memoria, ma non necessariamente quella ottimale. Tuttavia, a meno che non trovi (attraverso le misure!) Che il blocco rallenta notevolmente il tuo programma, probabilmente non vale la pena preoccuparsi delle alternative.

Problemi correlati