Programmazione

I tuoi 1.205 thread non vengono eseguiti contemporaneamente . Si scambiano. Un core esegue un po 'del thread, quindi lo mette da parte per eseguire un po' di un altro thread. Gli altri core fanno lo stesso. Rotondi e rotondi, i thread vengono eseguiti un po 'alla volta, non tutti in una volta.

Una delle principali responsabilità del sistema operativo (Darwin e macOS) è la pianificazione di quale thread deve essere eseguito su quale core per quanto tempo.

Molti thread non hanno lavoro da fare, e quindi rimangono in sospeso e non programmati. Allo stesso modo, molti thread potrebbero essere in attesa su alcune risorse, come i dati da recuperare dallo storage, o una connessione di rete da completare, o dati da caricare da un database. Con quasi nulla da fare se non controllare lo stato della risorsa attesa, tali thread sono programmati abbastanza brevemente se non del tutto.

Il programmatore di app può assistere questa operazione di pianificazione dormendo il suo thread per un certo periodo di tempo quando sa che l'attesa per la risorsa esterna richiederà del tempo. E se si esegue un ciclo "stretto" ad alta intensità di CPU senza motivo di attesa per le risorse esterne, il programmatore può inserire una chiamata al volontario da accantonare brevemente in modo da non incasinare il core e quindi consentire l'esecuzione di altri thread.

Per ulteriori dettagli, consulta la pagina di Wikipedia per il multithreading .

Multi-Thread simultaneo

Per quanto riguarda la tua domanda collegata , i thread ci sono in effetti gli stessi di qui.

Un problema c'è il costo generale del passaggio da un thread all'altro quando è programmato dal sistema operativo. C'è un costo significativo in termini di tempo per scaricare le istruzioni e i dati correnti del thread dal core e quindi caricare le istruzioni e i dati del prossimo thread programmato. Parte del lavoro del sistema operativo consiste nel cercare di essere intelligenti nella pianificazione dei thread per ottimizzare questo costo generale.

Alcuni produttori di CPU hanno sviluppato una tecnologia per ridurre questo tempo in modo da rendere il passaggio da una coppia di thread molto più veloce. Intel chiama la loro tecnologia Hyper-Threading . Conosciuto genericamente come simultanea multi-threading (SMT) .

Sebbene la coppia di thread non venga effettivamente eseguita contemporaneamente, la commutazione è così semplice e veloce che entrambi i thread sembrano essere virtualmente simultanei. Funziona così bene che ogni core si presenta come una coppia di core virtuali sul sistema operativo. Quindi una CPU abilitata SMT con quattro core fisici, ad esempio, si presenterà al sistema operativo come una CPU a otto core.

C'è ancora un sovraccarico nel passaggio anche tra questi core virtuali ottimizzati. Quindi, un amministratore di sistema può lanciare un interruttore sulla macchina per disattivare SMT se decide che sarebbe vantaggioso per i suoi utenti che eseguono un'applicazione che è insolitamente legata alla CPU con pochissime opportunità di pausa. In tal caso torniamo alla tua domanda originale: in questa situazione speciale vorrai davvero limitare le operazioni a non avere più di questi thread iperattivi di quelli che hai core fisici. Ma lasciatemelo ripetere: si tratta di una situazione estremamente insolita che potrebbe verificarsi in qualcosa di simile a un progetto scientifico specializzato di data crunching ma che non si applicherebbe quasi mai a scenari aziendali / aziendali comuni.

Ai vecchi tempi - la memoria non era virtualizzata o protetta e qualsiasi codice poteva scrivere ovunque. A quei tempi era logico un solo thread per un progetto di CPU. Nei decenni successivi, la memoria è stata prima protetta e poi virtualizzata. Pensa ai thread come a nuclei virtuali - una sorta di promessa che in un momento in cui i tuoi dati e il codice erano pronti, quel thread viene spinto ( o programmati come gli ingegneri ei matematici del PHD che fanno ricerche sugli algoritmi di schedulazione chiamano ) su una CPU reale per svolgere il lavoro effettivo.

• link

Ora-acausadell'ampiezzadelladifferenzaditempo-laCPUelacachefunzionanocosìvelocementerispettoaidatidastorageodallarete-chemigliaiadithreadpossonoandareevenirementreunthreadèinattesadiwww.google.comperfornireunpacchettooduedidati,eccoperchésivedonomoltipiùthreadrispettoallaCPUattuale.

Seconvertileoperazionidithreadcheavvengonosullascaladeltemponero/blueleconvertiinunsecondo=1ns,lecosecheciinteressanosonopiùsimiliaIOdeldisco:100microsecondisonocome4giornieunroundinternetdi200msilviaggioèunritardodi20annisesicontanoisecondisullascalatemporaledellaCPU.Come molti esercizi di dieci esercizi , in quasi tutti i casi - la CPU rimane inattiva per "mesi" in attesa di un lavoro significativo da un mondo esterno molto, molto lento.

Nulla sembra sbagliato nell'immagine che hai postato, quindi forse stiamo fraintendendo quello che stai facendo interrogandoti sui thread.

Se fai clic con il pulsante destro del mouse (clic del controllo) sui thread parola nella riga dell'intestazione in alto, aggiungi lo stato dell'app e vedrai che la maggior parte dei thread è probabilmente inattiva, inattiva, non in esecuzione in un dato momento.

Non si pone la domanda, probabilmente più fondamentale, "Come posso avere 290 processi quando la mia CPU ha solo quattro core?" Questa risposta è un po 'di storia, che potrebbe aiutarti a capire il quadro generale, anche se la domanda specifica ha già avuto risposta. Come tale, non ho intenzione di dare una versione TL; DR.

C'era una volta (pensate negli anni '50 -'60), i computer potevano fare solo una cosa alla volta. Erano molto costosi, riempivano intere stanze e avevamo bisogno di un modo per farne un uso efficiente condividendoli tra più persone. Il primo modo per farlo era l'elaborazione in batch , in cui gli utenti avrebbero inviato attività al computer e sarebbero stati messi in coda , eseguiti uno dopo l'altro e i risultati sarebbero stati restituiti all'utente. Era OK, ma voleva dire che, se volevi fare un calcolo che richiedeva un paio di giorni, nessun altro avrebbe potuto usare il computer durante quel periodo.

La prossima innovazione (pensate tra gli anni '60 e '70) era time-sharing . Ora, invece di eseguire l'intera attività, quindi l'intera di quella successiva, il computer eseguirà un po 'di un compito, quindi lo interromperà ed eseguirà un po' di quello successivo, e così via. Pertanto, il computer darebbe l'impressione che stesse eseguendo più processi contemporaneamente. Il grande vantaggio di questo è che ora puoi eseguire un calcolo che impiegherà un paio di giorni e, anche se ora richiederà ancora più tempo, perché continua a essere interrotto, altre persone possono ancora usare la macchina durante quel periodo.

Tutto ciò era per enormi computer in stile mainframe. Quando i personal computer hanno cominciato a diventare popolari, inizialmente non erano molto potenti e, hey, dal momento che erano personali , sembrava giusto per loro essere in grado di fare solo una cosa & nbdp; - eseguire un'applicazione - subito (pensa agli anni '80). Ma, man mano che diventavano più potenti (pensate, dagli anni '90 ad oggi), le persone volevano che anche i loro personal computer condividessero il tempo.

Quindi abbiamo finito con i personal computer che davano l'illusione di eseguire più processi contemporaneamente eseguendoli effettivamente uno alla volta per brevi periodi e poi interrompendoli. I thread sono essenzialmente la stessa cosa: alla fine, le persone volevano anche i singoli processi per dare l'illusione di fare più cose contemporaneamente. In un primo momento, lo sviluppatore dell'applicazione ha dovuto gestirli: passare un po 'di tempo ad aggiornare la grafica, metterla in pausa, passare un po' di tempo a calcolare, mettere in pausa, passare un po 'di tempo a fare qualcos'altro, ...

Tuttavia, il sistema operativo era già in grado di gestire più processi, aveva senso estenderlo per gestire questi sottoprocessi, che sono chiamati thread. Quindi, ora, abbiamo un modello in cui ogni processo (o applicazione) contiene almeno un thread, ma alcuni ne contengono molti o molti. Ognuno di questi thread corrisponde ad una sottoattività un po 'indipendente.

Ma, al livello più alto, la CPU sta ancora dando l'illusione che questi thread funzionino tutti allo stesso tempo. In realtà, ne viene eseguito uno per un po ', fermandolo, scegliendo un altro da correre per un po', e così via. Tranne che le moderne CPU possono eseguire più thread contemporaneamente. Quindi, nella realtà reale , il sistema operativo sta giocando questo gioco di "correre per un po ', mettere in pausa, eseguire qualcos'altro per un po', mettere in pausa" su tutti i core contemporaneamente. Quindi, puoi avere tutti i thread che desideri (e i tuoi progettisti di applicazioni) ma, in qualsiasi momento, solo alcuni di essi verranno effettivamente messi in pausa.