Capitolo 19: Sistemi real-time

Presentazione sul tema: "Capitolo 19: Sistemi real-time"— Transcript della presentazione:

1 Capitolo 19: Sistemi real-time

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

3 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;

4 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

5 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

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

7 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

8 Architetture

9 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 AvSys CMX RTOS

10 Struttura VxWorks

11 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)

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

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

14 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

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

16 Memory Management Unit

17 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

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

19 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).

20 Traduzione degli indirizzi nei sistemi real-time

21 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

22 Dead-line miss Deadline task Istante di arrivo

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

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

25 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

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

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

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

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

30 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

31 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à

32 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

33 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à.

34 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)

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

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

37 Scadenze non rispettate con lo scheduling a frequenza monotonica

38 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

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

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

41 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 );

42 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

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

44 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

45 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)

46 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() { } };

47 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() { } };

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

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

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

51 Fine del Capitolo 19