Indirizzi di memoria e assemblaggio

0

Recentemente ho iniziato a leggere sulla programmazione in Assembly. A mia conoscenza, in Assembly, un programmatore, quando memorizza e richiama le loro variabili, deve specificare l'indirizzo in cui sono memorizzate le loro variabili dal registro RAM alla CPU.

Ora la mia domanda è: cosa succede se in CPU multi-thread, due programmi eseguiti da un utente e entrambi i programmi cercano di accedere allo stesso indirizzo di memoria contemporaneamente durante la lettura o la scrittura, cosa succede? Come si potrebbe prevenire questo?

    
posta bi0phaz3 27.02.2016 - 06:11
fonte

3 risposte

1

Senza ulteriore coordinamento, almeno uno scrittore più un lettore può comportare una classica condizione di gara.

Ci sono una serie di fattori coinvolti.

Se è coinvolta solo una posizione di memoria (un byte o una parola allineata) è possibile che due thread, uno scrittore e un lettore, che accede alla stessa posizione, comunichino effettivamente. (L'allineamento è solitamente importante nel contesto del modello di memoria del professore, poiché i dati non allineati agiscono come due o più posizioni di memoria indipendenti)

Tuttavia, mantenere solo queste limitazioni non consente un'interazione generosa o ricca tra due thread.

Coinvolgere più di una posizione di memoria o più di uno scrittore e quasi sicuramente è necessaria la sincronizzazione esplicita.

Ci sono varie istruzioni del processore che facilitano la sincronizzazione.

Un set funziona come un atomico read-modify-write e consente a più writer di fare, tra le altre cose, di incrementare un contatore senza perdere alcun conteggio. Questi sono a volte implementati come istruzioni di confronto e scambio. Esistono numerose varianti, incluse le associazioni accoppiate collegate al carico e archiviate.

Ci sono anche istruzioni sulla barriera di memoria che dicono al processore qualcosa su quando e come svuotare le cache dei singoli processori nella memoria principale comune.

Queste primitive possono essere utilizzate per costruire serrature più grandi. La maggior parte dei sistemi operativi fornirà alcune ricche funzionalità di sincronizzazione dei thread che sono in qualche modo costruite su queste primitive hardware.

I linguaggi di programmazione e i sistemi operativi espongono queste primitive hardware attraverso metodi e metodi di bloccaggio sincronizzati. blocchi e variabili volatili.

Le transazioni e la memoria transazionale sono un'altra caratteristica molto interessante con un supporto hardware sottostante di base, ma è ancora molto nuovo.

    
risposta data 27.02.2016 - 07:52
fonte
0

Nella maggior parte dei moderni sistemi operativi, i processi in modalità utente vengono eseguiti in spazi di indirizzi virtuali isolati. Ciò significa che ogni processo ha una tabella che il processore usa per cercare dove viene effettivamente memorizzato un indirizzo di memoria generato da un programma in esecuzione. Poiché i tuoi due programmi hanno tabelle diverse, anche se entrambi tentano di accedere allo stesso indirizzo, la memoria a cui accederanno sarà diversa.

    
risposta data 27.02.2016 - 15:44
fonte
0

Che si tratti di due core CPU o di un contest tra altre periferiche, è certamente possibile che quelle cose accedano alla stessa risorsa "allo stesso tempo" ovviamente non è generalmente possibile essere "allo stesso tempo". La logica accoda le transazioni per una risorsa e le gestisce in un modo che funziona per quella risorsa. Quindi verranno ordinati.

È un problema estremamente comune, anche con una singola CPU, affrontare la condivisione delle risorse, è stato un problema sin dai tempi bui della programmazione e, come tale, ha avuto molte soluzioni. Ci devono essere centinaia / migliaia di risposte su questo sito per coprire questo argomento. Spesso si fa affidamento su un test e un set o altra caratteristica del processore o periferica che consente a un'applicazione / attività / thread di bloccare / riservare una risorsa, e fintanto che tutto il software (e / o la logica) che accede a tale risorsa condivisa è conforme a tale bloccando / condividendo quindi non avrete problemi. Nei vecchi tempi un semplice trucco consisteva nel disabilitare gli interrupt per una sezione di codice, ad esempio.

Nei primi giorni del PC abbiamo avuto il problema di Blinky in cui l'accesso della CPU alla ram del video era una priorità più alta dell'accesso del chip video a quella memoria e se il software stava accedendo alla memoria proprio quando la scheda video lo richiedeva, la scheda video avrebbe perso e ottenere spazzatura casuale o qualsiasi cosa rimanesse sul bus, chissà, la transazione fallirebbe, ma la scheda video dovrebbe ancora emettere un segnale, così si otterrebbero i caratteri cattivi lampeggianti sullo schermo per un aggiornamento, se il software continuasse a fare allora, dove si sono verificati questi lampeggiamenti, sembrerebbe casuale. Soluzione, condivisione, il software dovrebbe accedere alla RAM video solo durante una ritraccia verticale (o orizzontale) (ricorda CRT, richiede un po 'di tempo per cambiare l'energia nelle bobine per cambiare la mira del raggio per iniziare una nuova scansione orizzontale o spostare dall'angolo in basso verso l'alto)

Se la preoccupazione sta impedendo a chiunque altro di usare lo spazio della memoria perché non dovrebbero esserci per nessuna ragione, allora è stato risposto da altri. Gestito attraverso il mmu, che a meno che non si stia eseguendo bare metal, il sistema operativo ti ha fornito di RAM di tua proprietà, nessun altro può accedervi (oltre al sistema operativo). Il mmu è configurato in modo da avere uno spazio di indirizzamento virtuale che punta alla memoria fisica, ma ha anche controlli su chi può accedere a quella memoria e chi no, id thread / id virtuale, qualunque cosa, proprio come se si dovesse accedere alla memoria fuori dallo spazio, si otterrebbe un errore di protezione.

    
risposta data 28.02.2016 - 17:18
fonte

Leggi altre domande sui tag