|
Come avevo già scritto, anche cercando di limitare al minimo il numero di thread da esaminare, si perderebbe comunque troppo tempo: impossibile pensare anche soltanto di avvicinarsi a un O(1) dello scheduler di Linux, ad esempio.
Peggio ancora pensando di utilizzare un qualche algoritmo di ordinamento (a meno di non fare delle assunzioni e utilizzare altri algoritmo di ordinamento non basati sulla selezione, ma che comunque richiedono un tempo lineare per essere eseguiti).
Utilizzare delle liste anziché delle matrici comporterebbe non pochi problemi (attualmente Linux utilizza un vettore per memorizzare gli ID dei processi, di dimensione fissa), e aumenterebbe il tempo di esecuzione nel caso si volesse utilizzare un algoritmo di ordinamento.
Quanto al timer, nel sistema ce n'è soltanto uno che viene usato per segnalare il context-switch, e viene assegnato / usato da un solo processore, che fa da "master"...
A mio avviso l'idea di spostare la complessità dell'algoritmo dallo scheduler all'applicazione "particolare" consente di risolvere il problema, non pesando assolutamente sullo scheduler, e quindi su tutto il sistema: è una cosa non da poco.
Basti pensare al numero di processi / thread che girano su un sistema moderno: sono davvero tanti, e praticamente nessuno ha esigenze particolari. Se lo scheduler dovesse pensare a risolvere il problema del bilanciamento, per quanto bene fosse implementato l'algoritmo, "peserebbe" comunque su tutti i processi / thread, anche quando non sarebbe assolutamente necessario (che il caso più frequente).
|