In linea di principio, l'idea è buona e risolve un problema reale: cosa fai quando gli sviluppatori di altri due programmi hanno scelto le priorità 12 e 11 per i loro processi e hai bisogno che il tuo sia tra questi due?
Tuttavia, ci sono due problemi:
-
È necessario eseguire un ordinamento topologico del grafico di priorità ogni volta che viene creato un nuovo processo o viene modificata la sua priorità. L'algoritmo più noto per eseguire un ordinamento topologico online ha una complessità temporale amortizzata nel caso peggiore di qualcosa come O(√#edges)
. Ciò significa che la creazione di un processo sarà più lenta e più processi ci sono nel tuo sistema. Questo è inaccettabile, specialmente su sistemi come Unix e suoi cugini o Erlang, dove un processo è l'unità di base della decomposizione del programma, e si hanno migliaia (Unix) o addirittura decine di milioni (Erlang) processi su un sistema tipico.
-
Riceverai solo un ordine parziale. Cosa fai quando ci sono due processi che possono essere programmati ma non hanno un ordine definito tra loro? Quale si esegue per primo? In un campo completamente diverso, il linguaggio di programmazione Fortress ha un problema simile: Fortress non ha una tabella di precedenza degli operatori, invece la precedenza degli operatori è definita rispetto ad altri operatori (ad esempio +
ha la stessa precedenza di -
, *
ha una precedenza maggiore di +
) ecc. In Fortress, il mixaggio di due operatori che non hanno un ordine definito è semplicemente un errore di compilazione. Ma non puoi farlo con due processi, semplicemente rifiutati di avviarne uno.
Su un sistema "chiuso" in cui la serie totale di processi potenzialmente in esecuzione è completamente nota prima del runtime al momento dello sviluppo, puoi fare tutto il possibile per assicurarti che l'ordine sia totale, rilevare i cicli nel tuo grafico e ordinare topologicamente in fase di sviluppo. In effetti, questo è ciò che viene in genere fatto quando si sviluppano sistemi hard-realtime.