Ordine di elaborazione del thread multicore

Question

Ho qualche problema reale a trovare queste informazioni online, sono in uni lunedì, quindi potrei usare la biblioteca allora ma presto è meglio. Quando un sistema ha processori multicore, ogni processore prende un thread dal primo processo nella coda pronta o ne prende uno dal primo e uno dal secondo? Inoltre, per verificare, i thread verranno inviati e recuperati dai multicore contemporaneamente dal sistema operativo, giusto? Se qualcuno potesse indicarmi nella giusta direzione, sarebbe fantastico!

Answer 1

La cosa chiave è apprezzare ciò che è effettivamente l'architettura della macchina.

Un "core" è una CPU con cache con una connessione alla memoria del sistema. La maggior parte delle architetture delle macchine sono multi-processo simmetriche, il che significa che la memoria del sistema è ugualmente accessibile da tutti i core del sistema.

La maggior parte dei sistemi operativi esegue un thread Scheduler su ciascun core (Linux lo fa). Lo scheduler ha un elenco di thread di cui è responsabile e li eseguirà al meglio delle sue capacità sul nucleo che controlla. Le regole che utilizza per scegliere quale thread da eseguire sarà rotondo o basato sulla priorità, ecc.; cioè tutte le normali regole di pianificazione. Finora è proprio come uno scheduler che troveresti in un singolo computer core. In una certa misura, ogni programmatore è indipendente da tutti gli altri programmi.

Tuttavia, questo un ambiente SMP, il che significa che in realtà non importa quale core esegue il thread. Questo perché tutti i core possono vedere tutta la memoria e tutto il codice e i dati per tutti i thread nell'intero sistema sono archiviati in quella singola memoria.

Quindi gli Scheduler parlano tra loro per aiutarsi a vicenda. Gli scheduler con troppi thread da eseguire possono passare un thread a uno scheduler il cui core è sottovalutato. Stanno bilanciando il carico all'interno della macchina. "Passa un thread" significa copiare la struttura dei dati che descrive il thread (ID thread, quali dati, quale codice).

Quindi questo è tutto. Poiché l'unica comunicazione tra i core è attraverso la memoria, tutto si basa su un efficace sistema di semaforo di esclusione reciproca disponibile, che è qualcosa che l'hardware deve consentire.

La difficoltà

Quindi ho dipinto un'immagine molto semplice, ma in pratica la memoria non è perfettamente simmetrica. SMP in questi giorni è sintetizzato in cima a Hypertransport e QPI.

Sono lontani i giorni in cui i core avevano davvero pari accesso alla memoria del sistema a livello elettronico. Allo strato più basso della loro architettura amd sono puramente numera, e quasi così.

Oggi un core deve inviare una richiesta ad altri core su un collegamento seriale ad alta velocità (hypertransport o QPI) che chiede loro di inviare dati che hanno nella loro memoria allegata. Intel e AMD hanno fatto un buon lavoro nel renderlo in modo convincente SMP nel caso generale, ma non è perfetto. I dati in memoria collegati a un core diverso richiedono più tempo per ottenere. È follemente complesso - i core sono ora nodi su una rete - ma è quello che hanno dovuto fare per ottenere prestazioni migliorate.

Quindi gli programmatori lo prendono in considerazione quando scelgono quale core dovrebbe eseguire quale thread. Proveranno a posizionare un thread su un nucleo più vicino alla memoria che tiene i dati a cui il thread ha accesso.

Il futuro, di nuovo

Se l'ecosistema del software del mondo potesse essere svelato SMP, i ragazzi hardware sarebbero in grado di risparmiare molto spazio sul silicio e avremmo sistemi più rapidi più efficienti. Questo è stato fatto prima; I transputer sono stati un buon tentativo di un'architettura rigorosamente NUMA.

NUMA e comunicare i processi sequenziali renderebbero oggi molto più facile scrivere software multi -thread che si ridimensiona molto facilmente e funziona in modo più efficiente dei behemoth di memoria condivisa di SMP di oggi.

SMP era in effetti un modo economico e brutto di riunire più core e il costo in termini di difficoltà di sviluppo del software e hardware inefficienti è stato molto elevato.