Se stai parlando di threads supportati dall'hardware (Hyperthreading di Intel, per esempio), puoi cercare l'architettura del chip specifico che stai usando. Oppure, se conosci il numero di core fisici, gli strumenti del sistema operativo possono solitamente rivelare il numero di core virtuali nel sistema. Per esempio, il task manager di Windows sul mio portatile mostrerà otto CPU, ma in realtà ho solo quattro core, ognuno dei quali ha due thread hardware.
Questo non è certamente l'unico modo per farlo. E ci sono processori con fino a otto thread hardware (Dave Haynie'risposta a È possibile che un core della CPU abbia tre o quattro thread e come questo influisce sulle prestazioni?) Ma non è così probabile incontrarli, a meno che non si lavori in un centro dati.
Per quanto riguarda i thread software, ogni CPU [virtuale] ne ha uno. Il multithreading software è il multiplexing a divisione di tempo di una risorsa della CPU. Un thread funziona per un po', poi c'è qualche evento - un'attesa su una risorsa I/O, un timer a livello di sistema - che segnala uno scambio di compiti. Il sistema operativo guarda la coda dei compiti in sospeso per le priorità, e programma i prossimi N thread, uno per core virtuale. Ma finché il thread non è effettivamente in esecuzione, esiste come un pezzo di memoria da qualche parte, non è "su" alcun core.
È possibile, ma raro, che ad un thread sia assegnata specificamente una "affinità" per un core specifico in un sistema. Un esempio potrebbe essere una macchina virtuale - ci sono ottime ragioni per assegnare una VM ad un solo core. Alcune architetture di computer multiprocessing non sono completamente simmetriche. Per esempio, i primi sistemi multiprocesso Macintosh avevano solo una CPU che poteva gestire gli interrupt. Quindi tutta l'elaborazione degli interrupt doveva avvenire su quell'unica CPU, non importava quanti core aveste in realtà.
In termini di software, ci sono altre ragioni. Quando si dice "thread" nel software, di solito si sta parlando della più piccola unità di esecuzione del codice. Un thread praticamente si occupa solo del contesto della CPU stessa. Contro "processo", che include la gestione delle risorse e il monitoraggio delle allocazioni I/O, i contesti MMU, ecc. Posso scrivere un'applicazione multi-processo su sistemi basati su UNIX usando la funzione fork(), che è davvero facile da usare (divide un processo in due processi), ma usa molte risorse. Posso usare i thread sulla maggior parte dei sistemi operativi, che sono molto meno sovraccarichi. Tuttavia, ogni thread all'interno di un programma viene eseguito nello stesso contesto di processo. Quindi uno scheduler intelligente può rendersi conto che quando arriva il prossimo turno di programmazione, e scambiare i nuovi thread nello stesso contesto di processo, il che significa la stessa CPU. Nessun requisito per questo, solo un'ottimizzazione per ridurre l'overhead dello scheduling.