Newsgroup: it.comp.os.dibattiti
Titolo: real-time scheduling (OT?)

Ciao,
in cosa differisce un sistema multitasking in real-time (es. quelli usati nei sistemi embedded)
da uno tradizionale multi-thread? (es. windows) oppure da quello di Linux?
Su internet ho trovato alcuni sorgenti per lo sviluppo di scheduler di processi
sia in real-time che in multi-thread, ma non capisco dove sono le differenze.
In pratica volevo capire se era più efficiente il sistema multi-thread di windows
o quelli utilizzati nei sistemi embedded, tipo l'os della QNX, che appunto dovrebbe
utilizzare un real-time scheduling come descritto nel sito della QNX.
Siccome vorrei iniziare lo sviluppo di un sistema multitasking sperimentale con una gui nativa in 3d e
mi serve efficienza e stabilità, volevo sapere se qualcuno poteva spiegarmi queste differenze.
mi interessa l'efficienza in senso assoluto.
se avete informazioni da darmi vi ringrazio in anticipo.
Davide
(spero di non essere OT)

 differenze.
I controlli in real time hanno bisogno di certezze: cascasse il mondo, se
un certo segnale deve essere applicato ogni 20ms, il S.O. DEVE GARANTIRE
che il segnale venga applicato ogni 20 ms.
Specifiche del genere sono comuni in ambiti industriali dove la mancata
lettura di un sensore o la mancata apertura di un circuito possono
comportare la distruzione della macchina o danni alle persone. Per questo
motivo (di solito) i cicli o sono vietati o sono gestiti in modo molto
diverso dai normali microprocessori.
Questo garantisce che un PLC (tipico apparato in real time) non si pianti
a causa del software (pertanto nienete Windows sui PLC :-)).
Gli scheduler normali non hanno vincoli cosi' stretti questo consente
maggiore liberta' ai progettisti e maggiore semplicita' di sviluppo del
software ai programmatori (se non altro non hanno il vincolo che un
software debba essere eseguito in x ms)
HTH
C:\>iao Angelo
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 usati nei sistemi embedded) da uno tradizionale multi-thread?
La differenza e' simile a quella che c'e' tra un corriere espresso e le
poste.
Il sistema realtime deve garantire tempi di risposta certi alle applicazioni
che li richiedono ed obbedire quindi a vincoli piu' stringenti che un
normale time-sharing che normalmente si limita a distribuire (in modo piu' o
meno pesato in base alle priorita', ma comunque arbitrario) il tempo
macchina tra le applicazioni in esecuzione.
Non tutte le applicazioni embedded richiedono necessariamente il realtime,
ma certamente in questo settore si hanno gli esempi piu' significativi (hai
idea di cosa comporti un semaforo ferroviario che scatta in ritardo perche'
in quel momento il sistema stava swappando?)
Alessandro.

 ha scritto nel messaggio news:b3fpdo$sn$1...@news.newsland.it...
...[cut]...
grazie mille per le spiegazioni, penso di aver capito.
Ciao
Davide


La differenza concettuale tra i due sistemi non è molta ma è molta 
quella preatica: in un sistema non RT in teoria gli utenti possono far 
girare le applicazioni solamente ad un run level meno prioritario di 
quello del kernel in un sistema RT puoi far girare le applicazioni con 
la stessa priorità di esecuzione del codice nel kernel. Il kernel, poi, 
il più delle volte non è un processo vero e proprio ma consiste in una 
serie di macro (in C)che devono essere poste all'inizio all'interno (se 
necessario) ed alla fine di ogni funzione per incapsulare temporalmente 
il codice eseguito il tutto assistito da uno scheduler molto semplice 
fatto con una routine eseguita su un IRQ prioritario a tempo. 
Quest'ultima costituisce una specie di guardiano (wacth-dog) che ferma 
routine più lunghe del previsto e prende gli opportuni provvedimenti 
come la chiamata a pezzi di codice più prioritari in attesa (cheduler a 
priorità con preemption) oppure l'esecuzione di una routine di emergenza 
(scheduler a Round Robin senza preemption) ecc. ecc.

 (scheduler a Round Robin senza preemption) ecc. ecc.
Che non e` tipica solo dei sistemi RT.
In realta` un sistema RT semplicemente rende
possibile _sapere_ (e quindi controllare) i
timeline di esecuzione.
bye,
-- 
piergiorgio

 timeline di esecuzione.
Cos'è ? Potresti spiegarlo ?
Poi dipende dal sistema RT. Non mi riferivo a un sistema tipo RT-Linux 
come forse hai fatto tu ma a cose più "industriali", le uniche che ho 
potuto toccare con mano.
Poi penso che la tua definizione di sistema RT precluda il fatto che si 
possa fare una vera e propria distinzione....Io ho fatto un esempio di 
quello che per me è un sistema RT se tu vuoi farne un'altro non ci sono 
problemi a costo che non cominci a scrivere "non è vero".

 problemi a costo che non cominci a scrivere "non č vero".
Appunto, ma tu hai definito il sistema RT in
base ad uno specifico caso, cosa non vera.
Non e` che, siccome il DOS e` RT, allora tutti
i sistemi RT sono come il DOS...
bye,
-- 
   Piergiorgio Sartor


Tu consideri DOS un SO RT?
Alessandro.

 Tu consideri DOS un SO RT?
Lo e`.
RT, intendo, forse che sia un SO si
puo` discutere... :-)
bye,
-- 
piergiorgio

 Tu consideri DOS un SO RT?
non lo è? il processo in esecuzione ha quasi tutte le risorse a propria 
disposizione, e quando necessario può bloccare tutti gli interrupt
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.0. C, C++ and ASM developers
                               and beta testers are welcome!

 interrupt
Beh, potremmo dire con Piergiorgio che e' un non-OS RT, ovverossia il RT si
puo' implementare, ma il SO non da' servizi RT.
IMHO un SO RT e' tale se fornisce alle applicazioni servizi realtime.
Alessandro.

 IMHO un SO RT e' tale se fornisce alle applicazioni servizi realtime.
Questo il DOS lo fa in maniera naturale e
sistematica, cioe` non e` una scelta di
chi lo usa, ma avviene sempre e comunque.
bye,
-- 
   Piergiorgio Sartor


I servizi forniti da DOS sono interrompibili?
Alessandro.

 I servizi forniti da DOS sono interrompibili?
No, per questo e` RT.
L'interrompibilita` o meno di un servizio del SO
non determina il fatto che sia RT o meno.
Esempio di mioSO_RT:
...
for(;;) {
   read(data);
   process(data);
   write(data);
}
...
Questo semplice, patent free, SO e` RT.
Ha qualche limite, tipo non gestisce IRQ, ma si
puo` rimediare subito, garantendo pure la latenza:
...
for(;;) {
   read(data);
   process(data);
   write(data);
   if(irq == true) {
     process_irq();
   }
}
...
;-)
bye,
-- 
   Piergiorgio Sartor


A questo punto sono un po' confuso: quando e' che un SO non e' RT?
Alessandro.

 non determina il fatto che sia RT o meno.
Arihum...
Non sono un po' in contraddizione, le affermazioni di cui sopra?
-- 
"Everything is vague to a degree you do not realize till you have tried
  to make it precise"
                                       Bertrand Russell
                                       The Philosophy of Logical Atomism

 A questo punto sono un po' confuso: quando e' che un SO non e' RT?
Quando le tempistiche non sono prevedibili.
Il fatto che ci metta 1 uS od 10S per fare
qualcosa non importa, quello che conta e`
che sia prevedibile.
Ovviamente esistono casi in cui si puo` solo
determinare il caso peggiore, il che basta.
Il multitasking non e` necessario.
I sistemi non RT semplicemente non consentono
di controllare le tempistiche, avendo quindi
variabilita` troppo alta, non possono essere
considerati RT.
bye,
-- 
   Piergiorgio Sartor

 Non sono un po' in contraddizione, le affermazioni di cui sopra?
Non vedo perche`.
Il DOS (specifico SO) e` RT _anche_ perche` non
e` interrompibile.
L'interrompibilita` di un SO (generico, non DOS)
non determina il fatto che sia RT.
Spiego meglio: non e` che un SO RT debba essere
interrompibile, puo` anche non esserlo, come non
lo e` il DOS, che e` RT.
Cioe` interrompibilita` e RT sono indipendenti
in generale, ma nel caso del DOS (specifico SO)
la seconda e` anche conseguenza della prima.
E` ovvio, per esempio, che un SO non multitasking
e` sicuramente piu` RT di uno multitasking, ma
le due cose restano comunque indipendenti.
bye,
-- 
   Piergiorgio Sartor

 le due cose restano comunque indipendenti.
Non esiste una cosa come "più RT". O lo è, o non lo è.


 Non esiste una cosa come "più RT". O lo è, o non lo è.
Non e` affatto vero, dipende dalle situazioni,
e da cosa si vuole ottenere.
bye,
-- 
piergiorgio

Fabio Alemagna wrote:
[...]
Aspetta, forse ho capito dov'e` la confusione.
Quello che voglio dire e` che non si _decide_
se un SO e` RT per la sua possibilita` o meno
di interrompibilita`.
Cioe` non e` che se e` interrompibile e` RT o
viceversa. Una cosa non implica l'altra,
necessariamente, ma neanche nega l'altra.
Il DOS, per esempio, rappresenta il caso in cui
la non interrompibilita` puo` essere considerata
come una feature RT.
D'altro canto pSOS e` RT ed e` interrompibile.
Il giudizio "SO x e` RT" e` _indipendente_ da
questa caratteristica, il che non vuol dire,
pero` che questa non conti. Semplicemente non
e` generica, ma specifica.
bye,
-- 
piergiorgio


Allora quasi tutti i sistemi operativi sono RT (basta uno scheduler
roundrobin
e preemption).
Alessandro.

 roundrobin e preemption).
Roundrobin si.
Preemption... Ni.
Dipende da come viene gestita la politica
delle priorita`.
In generale, pero`, cooperative e` piu` RT
di preemptive.
Il punto e` che il controllo e` lasciato piu`
ai task che al SO, in genere, nei sistemi RT.
bye,
-- 
piergiorgio


Su un sistema operativo RT mi aspetterei che due task,
uno che campiona ogni 50 microsecondi e l'altro che
calcola continuamente l'FFT dell'ultimo milione di
campioni ricevuti possano coesistere senza sapere
nulla dell'esistenza dell'altro.
Alessandro.

 nulla dell'esistenza dell'altro.
I task forse si, chi realizza il sistema deve
sapere cosa succedera` e come le risorse siano
condivise tra le varie parti.
Non esiste SO RT in cui si lanciano applicativi
senza congnizione di causa e tutto continua a
funzioanre senza problemi.
Persino nei casi in cui le politiche di scheduling
e le priorita` sono gestite accuratamente, possono
verificarsi fenomeni "inconsueti", come l'inversione
di priorita`, che causano malfunzionamenti di tutto
il sistema.
Vedi il caso della sonda Pathfinder, in cui un task
a bassa priorita bloccava un task a priorita` piu`
alta, causando la perdita di dati...
(Sulla sonda c'era un SO RT).
bye,
-- 
piergiorgio

 Con il DOS con un SO RT generico?
Se c'entra con un SO RT generico c'entra anche con il DOS.


 Se c'entra con un SO RT generico c'entra anche con il DOS.
No, qui e` la tua confusione.
bye,
-- 
   Piergiorgio Sartor

 il sistema.
Non conosco il fenomeno dell'inversione della priorita'
(ha a che fare con i deadlock?).
Comunque l'accuratezza e' doverosa sempre. La preemption
puo' aiutare, ma certo non bisogna affidarsi solo a quella.
A parte questo discorso, si puo' dire che un SO RT deve
garantire che nessuna delle operazioni del SO blocchi le
applicazioni per un tempo indefinito(mi viene in mente
l'aumento dello swap file di windows, ma penso che ci siano
altri esempi...)?
Alessandro.

 altri esempi...)?
Indefinito od indefinibile.
Cioe` si deve sapere a priori e deve essere
il piu` "costante" possibile.
In aggiunta a questo, il SO RT deve consentire
un fine-tuning dell'esecuzione dei vari task in
tutto il sistema.
I task non sanno nulla, vedono solo se stessi
(comunicazioni inter-task a parte), ma il SO deve
consentire all'implementatore del sistema di
controllare completamente l'andamento del processamento.
bye,
-- 
piergiorgio


Questo l'avevo intuito ma non riesco ad immaginare
in quali condizioni questo possa avvenire (per
quanto a lungo possa attendere, un task di priota'
inferiore AFAIK non dovrebbe mai preeptare un task
di priorita' superiore).
Alessandro.

 di priorita' superiore).
E` una condizione complessa, che involve piu`
di due task, con interdipendenze fra di loro.
Forse, onde evitare inesattezze, si potrebbe
fare una ricerca con google.
Ad ogni modo il problema all'incirca avviene
quando un task ad alta priorita` ed uno a
bassa priorita` si scambiano in qualche modo
dati facendo si che un terzo task a media
priorita` non venga mai eseguito.
Dal punto di vista esterno si vede che il task
a bassa priorita` blocca quello a media.
bye,
-- 
   Piergiorgio Sartor

 lo trovo estremamente comodo.
Dimenticavo, questo non sempre e` possibile.
Ad es. certo SO RT non fanno il garbage
collection della memoria, per ovvi motivi.
Quindi se hai un applicazione che non e`
attenta a come la memoria e` allocata,
oppure non hai un layer apposito per
gestire la cosa, rischi di trovarti con
la memoria frammentata ed inutilizzabile.
bye,
-- 
   Piergiorgio Sartor

 di due task, con interdipendenze fra di loro.
L'inversione di priorità è un problema che affligge gli spinlocks, e 
probabilmente  altri tipi di locking, non lo scheduler in quanto tale. 
Si dice "inversione di priorità" non perché le priorità si invertono 
veramente, ma perché tutto funziona _come se_ le priorità si fossero 
invertite.


 invertite.
Ovvio.
bye,
-- 
   Piergiorgio Sartor


Grazie, ora e' un po' piu' chiaro.
Alessandro.