TinyOS: differenze tra le versioni

Versione delle 15:49, 11 dic 2023

Versione delle 21:51, 27 dic 2023

Riga 27:

== Modello di concorrenza ==

TinyOS è un sistema operativo totalmente non bloccante e l'intero [[ciclo di vita del software]] in esecuzione è di tipo event-driven. Ogni evento viene associato ad un interrupt che a sua volta è legato ad una sezione di codice di tipo Asynchronous Code -AC-. Sezioni di tipo AC possono essere invocata solo dagli interrupt e di conseguenza queste routine (riconoscibili poiché decorate tramite la keyword event) entrano a far parte del ''core'' del sistema stesso (possono essere pensate come le routine che vengono richiamate tramite il vettore degli interrupt in un sistema operativo standard).

L'assenza di primitive bloccanti è un grosso limite poiché può portare a situazioni di [[race condition]]. Tuttavia, nesC "risolve" tramite un [[workaround]] il problema permettendo l'uso della keyword "Atomic" all'interno del codice AC: la keyword può essere usata per decorare blocchi di codice da eseguire senza interruzioni. L'implementazione di questo costrutto richiede la disattivazione di tutti gli interrupt, l'esecuzione del codice (monopolizzando l'intero sistema) e la successiva riattivazione degli interrupt: pertanto, viene consigliato di rendere le sezioni atomiche quanto più piccole possibile per evitare di perdere eventi che nel frattempo potrebbero verificarsi.

Riga 43:

L'esecuzione dei task segue una politica First-Come First-Served tradizionale, senza diritto di prelazione (nonpreemptive).

Questo semplice modello di concorrenza funziona bene per applicazioni con prevalenza di operazioni di I/O (applicazioni I/O bound) ma può generare delle difficoltà per applicazioni con prevalenza di elaborazioni (applicazioni CPU bound). Sono state avanzate delle proposte per l'incorporazione del multi-threading al livello d'utente (a livello di sistema esistono dei thread di controllo) nel sistema, proprio per far fronte ad applicazioni CPU bound, ma è stato dimostrato che ciò avrebbe un impatto negativo sulle prestazioni del sistema stesso. Ad ogni modo, per motivazioni legate al [[risparmio energetico]], i mote delle reti wireless di sensori non dovrebbero svolgere elaborazioni intensive. Uno dei primi suggerimenti di TinyOS programming, il manuale di riferimento per i programmatori, recita: "Keep tasks short", "fai in modo che le sezioni di codice dei task siano brevi".

Gli scopi dichiarati dei progettisti di TinyOS sono:

Riga 52:

Per raggiungere questi scopi sono state fatte delle scelte che escludono l'utilizzo dei meccanismi delle interruzioni software e dei cambi di contesto (context switch); tali scelte massimizzano il rendimento della CPU, risorsa costosa in termini energetici.

All'atto della compilazione di un programma NesC, il codice dell'utente e quello delle componenti di sistema utilizzate vengono collegati staticamente e tradotti dal compilatore NesC in un unico file sorgente C; questo viene quindi processato dal compilatore C nativo che genera un unico [[file binario]] di dimensioni ridotte. Il sistema ha un unico stack riservato alle variabili locali e uno spazio di memoria riservato alle variabili globali (data). La memoria destinata al codice (text) del file binario eseguibile è assegnata in modo contiguo.

== Voci correlate ==