Capitolo 19: Sistemi real-time

Sistemi real-time Sistemi general pourpose Orizzonte degli eventi non definito: i task forse termineranno; Gestione della memoria elastica (es. paginazione,…); Sistemi real-time I task devono essere conclusi entro un lasso di tempo predefinito e predicibile; Di solito sono sistemi integrati/embedded (sistemi inseriti e nascosti in un dispositivo); Hanno risorse limitate e fisse; Sistemi safety-critical: il non completamento dei task pone problemi seri;

Sistemi real-time Sistemi Hard-realtime Hanno vincoli stringenti che impongono il completamento dei task Sistemi Soft-realtime Meno restrittivi; Assegnano priorità ai compiti real-time;

Sistemi real-time Specializzazione: Sono progettati per svolgere un solo di compito (o numero ristretto di compiti omogenei) Dimensione ridotta Es. forni, orologi; Processori a bassa potenza (es. 8 bit, 16 bit); Poca capacità di memorizzazione; Impronta (footprint): quantità minima di memoria richiesta dal SO e dalle applicazioni

Sistemi real-time Prodotto su larga scala Dovuto all’uso nelle apparecchiature di consumo Necessità di minimizzare i costi Limiti di tempo precisi Sfruttano particolari algoritmi di scheduling Minimizzano il tempo di risposta alle interruzioni

Architettura basata su bus Si usano strategie SOC (System On Chip) piuttosto che a BUS (come in figura) per contenere i costi

Architettura SOC Un SOC contiene: Uno o più core (es. microp. a DSP); Modulo di memoria (flash, rom, ram,…) Generatore di clock I connettori alle interfacce ADC/DAC

Architetture

Alcuni SO in tempo reale VxWorks (Motorola, Pentium, StrongArm, Arm) Aderisce a POSIX Robotica, controllo di processi, avionica, telecomunicazioni, medicina Prestazioni su Pentium 200: latenza media 1.7 us, latenza massima 6.8 us Windows CE .NET (ARM, StrongArm, XScale, MIPS, Pentium) Non aderisce a POSIX Prestazioni su Pentium 200: latenza media 2.4 us, latenza massima 5.6 us QNX Neutrino RTOS (Pentium, Power PC, ARM, StrongArm, XScale, MIPS, SH-4) Microkernel, aderisce a POSIX Prestazioni su Pentium 200: latenza media 1.6 us, latenza massima 4.1 us pSOSystem 3 Prestazioni su Pentium 200: latenza media 1.9 us, latenza massima 3.8 us Arx RTOS http://arx.snu.ac.kr/html/overview-arx.en.html AvSys http://www.avocetsystems.com CMX RTOS http://www.cmx.com

Struttura VxWorks

Windows CE OAL (OEM adaptation layer): si interfaccia con l’hardware (interrupt, timer, ioctl, …) KTL (Kernel Independent Transport Layer) supporto ai servizi di debugging GWES (Graphics, Windowing and Events)

eCos embedded Configurable operating system Open source Sistema operativo real-time progettato per sistemi embedded che richiedono un solo processo con thread multipli. Compatibile con lo standard Posix.

TinyOS Progettato per sensor network wireless (Smart Dust): limiti di memoria severi; È scritto in nesC come un insieme di task e processi cooperativi.

Caratteristiche dei kernel real-time Non hanno bisogno di strutture sofisticate a causa della loro specializzazione e dei costi connessi es.: Periferiche (CD, DVD, …) Protezione e sicurezza Utenti multipli Supporto dei dispositivi per alcune architetture nei kernel linux (ogni architettura ha anche dispositivi specifici): Option x86 ARM PPC MIPS SH M68k Parallel port support X   IEEE 1394 support IrDA support USB support Bluetooth support

Memory Management Unit Traduce indirizzi logici in indirizzi fisici, ma: Costano Consumano energia Il tempo di traduzione di un indirizzo può essere proibitivo se il TLB fallisce Sono necessari meccanismi più semplici per la gestione della memoria.

Memory Management Unit

Real-addressing mode Modalità di indirizzamento fisico: Gli indirizzi logici corrispondono a quelli fisici; Non ricorre alla memoria virtuale; Non ha meccanismi di protezione della memoria; Può obbligare i programmatori a dichiarare le locazioni fisiche in cui memorizzare le variabili Non consuma tempo per la traduzione degli indirizzi Viene usato nei sistemi hard real-time

Con registro di rilocazione L’indirizzo fisico si ottiene sommando il registro di rilocazione all’indirizzo logico. Anche in questo caso non c’è protezione della memoria.

Gestione completa della memoria virtuale La traduzione degli indirizzi avviene tramite la tabella delle pagine e il TLB. Protezione della memoria; Caricamento dei programmi in qualunque punto della memoria; Potrebbero addirittura gestire lo swapping su memoria flash (es. LynxOS).

Traduzione degli indirizzi nei sistemi real-time

Parametri dei task real-time Deadline relativa Tempo di calcolo e Deadline d task Istante di arrivo r Fine f Istante di avvio Tempo di risposta: f-r Laxity (Slack)=d-t-erem

Dead-line miss Deadline task Istante di arrivo

Vincoli di tempo Vincoli deterministici Es. tempo di risposta < 50ms Vincoli probabilistici Es. tempo di risposta > 50ms nell’1% dei casi

Uso della CPU Informazioni del carico di sistema: Fattore di uso della CPU: Frazione di tempo usata nell’esecuzione dei task

Uso della CPU <25% Eccesso di potenza di calcolo: la CPU probabilmente è troppo potente <50% Zona sicura <68% Zona “abbastanza” sicura 69% Limite teorico 70-82% Zona non sicura 83-99% Zona pericolosa (ma usata nei sistemi embedded) >100% Overload

Scheduling per priorità Il SO real-time deve rispondere immediatamente a un processo quando questo richiede l’uso della CPU: E’ necessario uno scheduler con diritto di prelazione Se lo scheduler supporta priorità e prelazione un processo con priorità più alta può far sospendere uno con priorità più bassa attualmente in esecuzione. Questi tipi di scheduler si usano nei casi soft real-time.

Kernel con diritto di prelazione Consentono la prelazione dei processi eseguiti in modalità kernel. Sono necessari per sistemi hard real-time. Si realizzano con l’inserimento di punti di prelazione all’interno delle system call. Un punto di prelazione verifica che un processo ad alta priorità sia pronto a partire. In questo caso c’è un cambio di contesto. I punti di prelazione possono essere inseriti solo in punti sicuri: quando le strutture del kernel non subiscono modifiche Possono essere implementati anche con sistemi di sincronizzazione.

Minimizzazione della latenza I sistemi real-time sono guidati dagli eventi Latenza relativa ad un evento (event-latency): il periodo tra l’inizio di un evento e il momento in cui le azioni necessarie per gestirlo sono intraprese dal sistema.

Latenza relativa alle interruzioni Periodo tra la notifica di un’interruzione e l’avvio della routine di gestione dell’interruzione.

Latenza relativa alle interruzioni Durante l’aggiornamento delle strutture dati del sistema le interruzioni sono disattivate nei sistemi real-time questi periodi devono essere molto piccoli nei sistemi hard real-time la latenza deve essere circoscritta

Latenza relativa al dispatch Periodo tra il blocco di un processo e l’avvio del successivo. Prelazione dei processi in esecuzione Cessione delle risorse al processo ad alta priorità

Inversione delle priorità Tre processi L, M, H Priorità L<M<H H richiede la risorsa R usata da L Se M diviene eseguibile e ha prelazione su L, l’attesa di H si prolunga Protocollo di inversione delle priorità: i processi che accedono a risorse già richieste da processi a priorità più alta ereditano tale priorità fino a quando hanno terminato di usarle: L eredità la priorità di H in modo da non poter essere interrotto da M

Processo periodico 0 < t < d < p Lo scheduler può usare quest’informazione per assegnare le priorità: il processo deve dichiarare d; lo scheduler esegue un controllo dell’ammissibilità.

Scheduling a frequenza monotonica Modello statico di attribuzione delle priorità con prelazione Ipotesi: Priorità inversamente proporzionale al periodo (statica) Non c’è condivisione delle risorse Il periodo non varia. E’ un algoritmo ottimale (per gli scheduler a priorità statiche)

Scheduling dei processi in caso P2 abbia priorità maggiore di P1 Scadenze: p1 = 50 p2 = 100

Scheduling a frequenza monotonica A priority is assigned based on the inverse of its period Shorter periods = higher priority; Longer periods = lower priority P1 is assigned a higher priority than P2.

Scadenze non rispettate con lo scheduling a frequenza monotonica

Scheduling EDF Earliest Deadline First Scheduling Priorities are assigned according to deadlines: the earlier the deadline, the higher the priority; the later the deadline, the lower the priority. Ogni processo deve dichiarare la propria deadline ATTENZIONE all’effetto domino

Proportional Share Scheduling T shares are allocated among all processes in the system. An application receives N shares where N < T. This ensures each application will receive N / T of the total processor time.

Pthread Scheduling The Pthread API provides functions for managing real-time threads. Pthreads defines two scheduling classes for real-time threads: (1) SCHED_FIFO - threads are scheduled using a FCFS strategy with a FIFO queue. There is no time-slicing for threads of equal priority. (2) SCHED_RR - similar to SCHED_FIFO except time-slicing occurs for threads of equal priority.

Esempio: creazione di un task in FreeRTOS // Task to be created. void vTaskCode( void * pvParameters ) { for( ;; ) // Task code goes here. } // Function that creates a task. void vOtherFunction( void ) unsigned char ucParameterToPass; xTaskHandle xHandle; // Create the task, storing the handle. xTaskCreate( vTaskCode, "NAME", STACK_SIZE, &ucParameterToPass, tskIDLE_PRIORITY, &xHandle ); // Use the handle to delete the task. vTaskDelete( xHandle );

RTSj Real-Time Specification for Java (RTSJ) RTSJ is designed to support both hard and soft real-time applications. scheduling properties suitable for real-time applications with provisions for periodic and sporadic tasks, support for deadlines and CPU time budgets, tools to let tasks avoid garbage collection delays

Esempio: gestione della memoria in real time java The RTSJ defines two new types of memory areas that allow real-time applications to avoid unpredictable delays commonly caused by traditional garbage collectors: Immortal memory holds objects without destroying them except when the program ends. This means that objects created in immortal memory must be carefully allocated and managed.

Esempio: gestione della memoria in real time java Scoped memory is used only while a process works within a particular section, or scope, of the program such as in a method. Objects are automatically destroyed when the process leaves the scope. This is a useful feature akin to garbage collection in that discrete creation and deletion is not required as in the immortal memory case - but the process must be sure to exit the scope to ensure memory is reaped. Neither immortal nor scoped memories are garbage collected, so using them avoids problems of GC interference

Real Time Specifications for Java (RTSJ) Memory management Classe ScopedMemory: sottoclassi: VTMemory (allocazioni fornite in un tempo variabile) e LTMemory (allocazioni fornite in un tempo lineare proporzionale alla grandezza dell'oggetto)

Real Time Specifications for Java (RTSJ) Memory management RTSJ introduce due nuove aree di memoria nelle quali il Garbage Collector agisce in modo predicibile immortal memory: condivisa tra i thread di un'applicazione. Rilascio solo al termine. ImmortalMemory.instance().enter(new Runnable() { public void run() { } };

Real Time Specifications for Java (RTSJ) Memory management Scoped memory. Definisce limiti di vita di un oggetto; numero dei riferimenti a quell'area. Se == 0 la memoria viene rilasciata (metodi finalize() di quegli oggetti) public void run() { LTMemory myMem = new LTMemory(1000, 5000); // LTMemory (initialSize, maxSize in byte) myMem.enter(new Runnable() { } };

Esempio: gestione della memoria in real time java Direct Access to Physical Memory While still maintaining security protections, the RTSJ allows direct access to physical memory. This means that device drivers can be created written entirely in Java. Previously, Java applications had to link to native code to communicate directly with the hardware.

Esempio JavaRTS RealtimeThread thread class—Used for soft real-time scheduling, this class uses a real-time garbage collector. NoHeapRealtimeThread thread class—This class is used for hard real-time scheduling and synchronization (does not use the Java heap, and hence does not need the garbage collector). Twenty-eight new levels of strictly enforced priority levels. The highest priority Java RTS thread is truly the highest priority thread in the system and will not be interrupted.

Esempio JavaRTS Asynchronous event handlers —These handle external events and allow you to schedule your application’s response without spoiling the temporal integrity of the overall system. Asynchronous transfer of control —This allows you to transfer control from one thread to another or quickly terminate a thread, in a manner that is safe from a real-time perspective. High-resolution timers —These timers have true nanosecond accuracy.

Fine del Capitolo 19