E 'un successo in termini di prestazioni creare thread che si collegano molto per controllare le cose?

In general, is it intensive for a CPU to create threads that perform "while not true ..." loops or similar?

Sì. L'utilizzo di tale ciclo si chiama busy waiting e viene chiamato per un motivo. Questi loop occupati controllano la condizione con la frequenza e la velocità con cui il processore può gestirlo, con il risultato che, se si rimane nel loop abbastanza a lungo, il carico del processore passa in modo affidabile al 100%.

What if I create 1000 threads that all do the same loop? How might that affect performance/CPU cycles?

Crea solo più lavoro per la CPU che sta facendo attenzione.

Furthermore, is this how events function internally? When you're 'listening' for an event in Java, .NET, Javascript etc (such as a button press or a window resize), has a thread that loops been created?

No. I loop occupati sono una forma di sondaggio e anche molto inefficiente. I sistemi operativi hanno altri meccanismi per rilevare che un evento si è verificato (ad esempio un interrupt o una chiamata specifica) e hanno meccanismi per consentire ad un thread di attendere senza consumare tempo della CPU. Questi meccanismi saranno utilizzati anche per implementare i meccanismi degli eventi di linguaggi come Java.

Il tuo istinto è corretto. Occupato-attesa come quello descritto come

Spinning can be a valid strategy in certain circumstances, most notably in the implementation of spinlocks within operating systems designed to run on SMP systems. In general, however, spinning is considered an anti-pattern and should be avoided, as processor time that could be used to execute a different task is instead wasted on useless activity.

Invece, dovresti considerare una primitiva di controllo della concorrenza che permetta al thread di andare veramente inattivo finché non ha un lavoro utile da fare, ad esempio un semaforo o una variabile di condizione :

For many applications, mutual exclusion is not enough. Threads attempting an operation may need to wait until some condition holds true. A busy waiting loop, like

while not( condition ) do 
   // nothing
end

will not work, as mutual exclusion will prevent any other thread from entering the monitor to make the condition true. Other "solutions" exist. Such as having a loop that unlocks the monitor, waits a certain amount, locks the monitor and check for the condition P. Theoretically, it works and will not deadlock, but issues arise. It's hard to decide an appropiate amount of waiting time, too small and the thread will hog the CPU, too big and it will be apparently unresponsive. What is needed is a way to signal the thread when the condition P is true (or could be true). The solution is condition variables. Conceptually a condition variable is a queue of threads, associated with a monitor, on which a thread may wait for some condition to become true. Thus each condition variable is associated with an assertion . While a thread is waiting on a condition variable, that thread is not considered to occupy the monitor, and so other threads may enter the monitor to change the monitor's state. In most types of monitors, these other threads may signal the condition variable to indicate that assertion is true in the current state.

I thread devono attendere gli eventi in arrivo, non le modifiche alle variabili.

Gli eventi in arrivo stanno rendendo disponibili i semafori, le code dei messaggi che diventano non vuote o il tempo trascorso:

semGet()
msqRead()
sleep()

Dal punto di vista del thread, queste chiamate di funzione stanno bloccando: il thread attende fino a quando l'evento è arrivato, lasciando il carico della CPU ad altri thread.

Dal punto di vista del sistema, il thread è contrassegnato come "In attesa dell'evento" e non verrà programmato finché l'evento non è arrivato.

Riguardo agli eventi hardware, vengono gestiti tramite interrupt che sono segnali elettrici alla CPU e che attivano l'esecuzione di ISR (routine di servizio di interrupt), il cui ruolo è di produrre un evento software su semafori, code di messaggi o tempo.

La parte //do nothing dentro mentre la condizione nello scenario normale è WAIT su qualche semaforo, o in altri termini SLEEP. Dormi fino a quando qualche interruzione ti ha svegliato. E quindi il thread va in "sleep state" o lascia solo dire "non in esecuzione". Solo i processi che sono in esecuzione consumano CPU. Il processo dello stato di sospensione non consuma la CPU. Possono consumare memoria, ma quella memoria verrà sostituita internamente dal sistema di memoria virtuale. Quindi, anche se crei 1000 thread di questo tipo, non porteranno molte minacce al tuo sistema.