Potremmo impostare le priorità solo l'una rispetto all'altra invece dei numeri fissi?

1

AFAIK la priorità più bassa ha il numero più alto nella programmazione e nel mio sistema tutte le priorità devono essere diverse. Ma non sono pensabili altre politiche? Ad esempio, che ne dici di una politica in cui le priorità non sono numeri ma che la priorità di un'attività sarà definita solo in base alla priorità di un'altra attività e che l'altra attività sarebbe la priorità più vicina all'attività di cui stiamo impostando la priorità. Quindi non useremmo mai numeri reali per le priorità, ma terremmo una struttura dati che ordina i compiti in priorità e quando un compito viene come nuovo o viene assegnata una priorità diversa, allora questa struttura viene ribilanciata. Questo meccanismo prioritario sarebbe fattibile o non sei d'accordo sul fatto che sia un'idea funzionante?

    
posta Niklas Rosencrantz 07.10.2013 - 11:31
fonte

2 risposte

6

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:

  1. È 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.

  2. 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.

    
risposta data 07.10.2013 - 12:31
fonte
1

Perché è necessario? Non c'è nulla che ti impedisca di progettare un sistema di priorità superflessibile, ma, a meno che non risolva effettivamente un problema reale, aggiungendo la complessità aggiuntiva a qualcosa di così importante come lo scheduler sarà difficile da vendere.

Una soluzione più semplice sarebbe quella di mettere un demone nello spazio utente in grado di dire periodicamente al kernel di aggiornare le priorità dei processi in esecuzione mentre nuove relazioni vengono messe in atto. Ciò manterrebbe il codice di programmazione dello spazio del kernel semplice e amp; efficiente pur consentendo tutta la flessibilità di cui hai bisogno.

    
risposta data 07.10.2013 - 18:49
fonte

Leggi altre domande sui tag