Newsgroup: it.comp.os.dibattiti
Titolo: Solaris 8 Real-Time?

Negli answerbook di Solaris 8 c'e' una piccola sezione dedicata a descrivere
rapidamente le nuove funzionalità del sistema operativo. A proposito del
real-time ci sono scritte le informazioni che seguono.
Secondo voi e' quindi possibile asserire dopo questi miglioramenti che
Solaris 8 sia un sistema operativo totalmente real-time?
Timer ad alta risoluzione
I timer ad alta risoluzione (HRT) "escludono" la tradizionale interfaccia a
100 millisecondi per evidenziare in maggiore dettaglio gli interrupt fisici
del clock generati dall'hardware. In questo modo, l'interfaccia HRT permette
a un processo in tempo reale di assumere il controllo di un singolo
processore (di un sistema multiprocessore) e di operare con il grado di
precisione desiderato negli eventi di sincronizzazione.
Si tratta dell'ultimo elemento richiesto per poter eseguire le tradizionali
applicazioni in tempo reale sotto Solaris.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^
Per maggiori informazioni, vedere il manuale System Interface Guide.
Ereditarietà delle priorità a livello utente
Le applicazioni in tempo reale (RT) possono eseguire più thread alla volta
nella classe di scheduling in tempo reale. È possibile che un thread RT a
bassa priorità ottenga un lock ad esclusione reciproca per una certa
risorsa, e che tale risorsa venga successivamente richiesta da un thread RT
con priorità più elevata. In questo caso, il thread ad alta priorità deve
attendere che il thread a bassa priorità abbia terminato l'operazione e
rilasci il lock. Questa condizione viene detta "inversione delle priorità".
I thread RT implementano le interfacce POSIX (in precedenza solo simulate)
che permettono a un thread ad alta priorità di "prestare" tale priorità ad
un thread di priorità inferiore fino al rilascio del lock.
I thread RT che utilizzano l'ereditarietà delle priorità (o il cosiddetto
"tetto" dei lock) dovrebbero usare lo scheduling PTHREAD_SCOPE_SYSTEM (o i
thread associati). I thread non associati utilizzano lo scheduling
PTHREAD_SCOPE_PROCESS e non sono adatti per le esigenze delle applicazioni
in tempo reale.
Per maggiori informazioni, vedere il manuale Multithreaded Programming
Guide.

un thread di priorità inferiore fino al rilascio del lock.
Ah forse ho capito, in pratica il thread a priorita` piu` bassa
esegue cio` che sta` dentro il lock a priorita` piu` alta?
In questo modo andrebbe piu` veloce?
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)

 In questo modo andrebbe piu` veloce?
Esattamente!
 Comunque non so se questo permetta di andare piů veloce perň sempre dallo
stesso url SUN assicura di sě
Improvements have been made to event latency by assuring that any blocking
thread -- of a lower priority than the real-time process -- has its priority
increased to quickly complete and release the blocked resource
Ciao
UltraSparc

 ovviamente dipende dalla piattaforma). Dal sito Sun
fino ad un CHE?
stai scherzando vero?
non mi risulta che si sia arrivati ad una risoluzioni di un nanosecondo.
fosse per caso microsecondo?
piu' plausibile penso.

fosse per caso microsecondo?
Anche, man usleep


 In questo modo andrebbe piu` veloce?
Un problema simile si era verificato con la sonda "Pathfinder",
su Marte, mi pare di ricordare fosse una cosa del genere:
vi erano tre task a priorita` decrescente, il primo (massima
priorita`) aspettava (o mandava) dati dal terzo (priorita` piu`
bassa), questo pero` era bloccato dal secondo, che rispetto a
al terzo aveva piu` priorita`.
Quindi il primo task risultava bloccato dal secondo, che aveva
priorita` piu` bassa, cioe` le priorita` si erano invertite.
Questo usando un OS RT (mi pare fosse VxWorks), che ha, appunto,
un meccanismo di scheduling RT (e non Unix like).
bye,
--
  Piergiorgio Sartor

increased to quickly complete and release the blocked resource
Se e` vero buon per loro.
Credo che per fare una cosa del genere serva un kernel preemptive,
non multitasking preemptive, quella e` un'altra cosa.
Solaris dovrebbe essere un kernel preemptive infatti mentre Linux no.
Inutile dire che ci sono vantaggi e svantaggi, con un kernel come
quello di Solaris si ha un controllo piu` "fine" nell'esecuzione delle
diverse parti del kernel aumentando la scalabilita` nei sistemi SMP.
D'altra parte la complessita` che ne deriva e` mostruosa, ho sentito
dire che Solaris abbia qualche _migliaio_ di spinlocks. Al confronto
quelli di Linux si contano con una o due mani.
Larry McVoy che ha lavorato su SunOS e Solaris dice che la strada
giusta e` quella di Linux. Secondo lui le alte prestazioni in SMP
possono essere raggiunte senza tutta quella complessita` e trovando
un compromesso migliore. Se il 2.4 manterra` le attese potremo ben
dire che Larry aveva ragione :-)


 Non esistono solo i PC, per fortuna.
si, ma non esistono neanche piattaforme da un nanosecondo, a meno che non
reinventare momentaneamente la fisica attuale

 Non esistono solo i PC, per fortuna.
E, soprattutto, non solo PC con Windows :-))
Ciao
UltraSparc

reinventare momentaneamente la fisica attuale
Basterebbe usare il clock del processore.
I Pentium hanno un registro a 64 bit (accessibile indirettamente)
il cui valore viene incrementato (o decrementato?) ogni ciclo di clock.
Ora non mi ricordo se al termine del conteggio venga invocato qualche
interrupt ma se cosi` fosse si potrebbe avere un contatore molto preciso.
Un clock di 100Mhz ha un periodo di 10^-8 secondi = 10 nano secondi.
Poi visto che ormai siamo vicini al Ghz...


 dire che Larry aveva ragione :-)
Mi dai gli url dove hai trovato le dichiarazioni di McVoy?
Credi che si faranno dei confronti diretti fra linux 2.4 e Solaris 2.8 su
Sparc?
Ciao
UltraSparc

Sparc?
Come no, basta configurare due macchine uguali.


Poi visto che ormai siamo vicini al Ghz...
Si vabbe' e poi cosa esegui tra un interrupt e l'altro ? Non hai il tempo di
eseguire nulla : se ad ogni ciclo di clock ( si sta parlando di una
risoluzione di 100MHZ su di un 100MHZ ) richiami un interrupt, non puoi
esgure alcuna instruzione, richiedendo questa almeno un ( ed in generale 
molti di piu' ) ciclo di clock ( senza considerare il salvtaggio dei dati
nello stack .... )

 dire che Larry aveva ragione :-)
Da quello che ho capito Larry McVoy sostiene che sia più efficiente l'
esecuzione di una istanza del SO da parte di uno o più processori con una
parte di memoria condivisa per permettere la coerenza fra le varie istanze
(ho capito bene?)
D' altra parta mi sembra la stessa strada percorsa da Sun/Solaris. D' Itri,
infatti, quando gli nominai l' Enterprise 10000 (64 processori), mi disse
che l' architettura usata in quei casi è NUMA e non SMP. Effettivamente,
rileggendo anche il pdf su NUMA e una breve documentazione SUN che ho in
ufficio, si vede che in queste macchine le risorse sono organizzate in dei
domini su ognuno dei quali gira una particolare istanza dell' OS.
Purtroppo oltre non riesco ad andare. Spero che anche altri si facciano
avanti per approfondire l' argomento che credo abbastanza interessante
(anche se a giudicare dal numero di reply al post, sembra interessante solo
a me)
Ciao
UltraSparc

 Poi visto che ormai siamo vicini al Ghz...
Su comp.unix.solaris ho letto che su Sparc è possibile aumentare il clock
fino a 1000 Hz settando una variabile del kernel (hires_tick). Certo 1000 Hz
non sufficienti per la nano risoluzione.
Però ho trovato anche un url interessante per il real-time in Solaris:
http://www.sun.com/software/white-papers/wp-realtime/
Lo sto ancora leggendo. Forse dice qualcosa di nuovo
Ciao UltraSparc

nello stack .... )
No, l'interrupt lo chiama al termine del conteggio non ad ogni ciclo
di clock. Leggi bene quello che ho scritto.
Certo che se setto il contatore a 1 avro` un interrupt ad ogni ciclo
ma il contatore va usato per avere la *risoluzione* di un nano secondo
non per misurare tempi del nano secondo.


a me)
E' interessantissimo, peccato che non sia in grado di intromettermi nella
discussione :-/
-- 
*** Hi! I'm a .signature Virus ! Copy me
    to your signature to help me spreading! ***