Informatica Industriale - 11

Transcript

1 Informatica Industriale - 11 Parallelismo e Sistemi Operativi Real-Time - Cap. 10 prof. Lorenzo MEZZALIRA Modelli implementativi di parallelismo Modello a Processi Sequenziali Comunicanti Scheduling Temporale Interruzioni - Priorità e annidamento Competizione e cooperazione Primitive di S.O. multitask Cap Sistemi Operativi Real-Time - Lucido 0

2 INTRODUZIONE Gli obbiettivi di un sistema di elaborazione possono essere svariati e concomitanti, come ad esempio: semplicità ed economia massimo sfruttamento di alcune risorse (video, dischi) massimo throughput di elaborazione adeguatezza alle esigenze di una multiutenza rispetto di vincoli temporali nelle interazioni con l esterno massima affidabilità La personalità del sistema, sia rispetto all interazione con l operatore sia rispetto alle funzioni offerte ai programmi applicativi, dipende notevolmente dal tipo di macchina virtuale che il sistema operativo implementa sulla macchina fisica. Il SW applicativo infatti si appoggia (in genere) al supporto del S.O. Cap Sistemi Operativi Real-Time - Lucido 1

3 NECESSITÀ DI PARALLELISMO (Per l elaborazione in tempo reale) Il carico di lavoro di un sistema di elaborazione che debba interagire in tempo reale con fenomeni esterni è scomponobile, come già presentato nel cap. 2, in: attività costituite da azioni periodiche (campionamenti, monitoraggio, regolazioni, ecc.) azioni aperiodiche (generalmente risposte ad eventi sporadici) attività di sottofondo (non real-time). Chiamiamo scopo temporale ST di un'azione l'intervallo di tempo tra l'istante in cui si verifica l'evento che consente o richiede l'esecuzione dell'azione (triggering event) e l'istante di tempo in cui tale attività è, o deve (deadline) essere, completata. ST = TLatenza + TEsecuzione Cap Sistemi Operativi Real-Time - Lucido 2

4 PARALLELISMO Chiamiamo concorrenti attività le cui azioni hanno scopi temporali che presentano sovrapposizioni (overlapping), in contrapposizione al termine sequenziali che designa azioni con scopi temporali senza intersezioni. Un'elaborazione ad attività concorrenti non è necessariamente di tipo realtime. E real-time solo un'elaborazione in cui l'inizio e/o la fine di alcuni o tutti gli scopi temporali delle azioni è vincolata da specifiche temporali. Chiamiamo processo sequenziale un'attività internamente sequenziale e caratterizzata da un proprio contesto, cioè l'insieme delle risorse ad essa allocate ed i rispettivi stati. Le risorse possono essere attive (processori di vari tipi) o passive (periferiche, memoria, dati, ecc.). L esecuzione di un processo richiede una risorsa attiva ed eventualmente un certo numero di risorse passive. Cap Sistemi Operativi Real-Time - Lucido 3

5 PARALLELISMO I sistemi di elaborazione in tempo reale devono essere dotati di una capacità di parallelismo tra diverse elaborazioni, cioè la capacità di iniziare e completare in tempo una nuova azione anche se altre sono già in corso (sovrapposizione di scopi temporali di diverse azioni). Chiamiamo: TDi la durata dello scopo temporale dell'azione i-esima (esprime la rapidità di risposta richiesta al sistema di elaborazione) detta DEADLINE. TEi il massimo tempo di esecuzione netto dell'azione i-esima (esprime la velocità offerta dal sistema di elaborazione). Condizione sufficiente perchè sia richiesto un parallelismo di esecuzione (eventualmente con preemption) è che esistano almeno due eventi tra loro aperiodici, tali per cui sia: TDi < TEi + TEj Cap Sistemi Operativi Real-Time - Lucido 4

6 PARALLELISMO FISICO Un totale parallelismo reale (o fisico) è ottenibile solo se sono disponibili tante risorse processori (multiprocessing), quante sono richieste dalle diverse attività potenzialmente concomitanti. In questo caso le latenze sono nulle. Questo parallelismo implica un'assegnazione (scheduling) spaziale delle attività alle risorse. Ogni risorsa rimane inattiva (idle) per tutto il tempo in cui non è richiesto lo svolgimento di azioni dell'attività assegnatale, e ciò può portare ad uno scarso sfruttamento di tali risorse. Quindi generalmente non si adotta una configurazione a risorse illimitate. Un'applicazione non è fisicamente realizzabile, neppure con un sistema a parallelismo fisico, se per almeno un'azione si ha: TEi > TDi che corrisponde a potenza di calcolo insufficiente per l algoritmo adottato, rispetto alle prestazioni temporali richieste. Cap Sistemi Operativi Real-Time - Lucido 5

7 PARALLELISMO VIRTUALE Molto interessante è il parallelismo virtuale (o logico) che è ottenibile con l'assegnazione nel tempo delle (scarse) risorse, alle azioni in corso durante intervalli di tempo interni ai rispettivi scopi temporali (multitasking). Richiede uno scheduling temporale che consente un migliore sfruttamento delle risorse rispetto al parallelismo esclusivamente fisico. Il tempo di elaborazione di un azione corrisponde a tempo di latenza per tutte le altre azioni che in quel momento hanno scopo temporale sovrapposto. Ricordiamo il coefficiente di utilizzazione del processore: ntei U = 1 TA i n = numero di azioni potenzialmente richieste al processore TEi = tempo (max) di esecuzione netto dell'azione i-esima TAi = intervallo (min) tra le attivazioni dell'azione i-esima. La realizzabilità fisica con un solo processore impone che sia U < 1 che è condizione necessaria, ma non sufficiente (dipende dalle politiche di scheduling), perchè possano essere rispettati tutti i vincoli temporali. Cap Sistemi Operativi Real-Time - Lucido 6

8 PARALLELISMO VIRTUALE Carico di lavoro della CPU Per il carico di lavoro imposto da eventi periodici i valori TAi corrispondono ai periodi dei rispettivi eventi, Per le componenti del carico di lavoro imposte da eventi sporadici si può parlare di utilizzazione "media" o "di picco" a seconda che per i vari TAi si adottino i valori medi o minimi (tempo morto) di ripetizione del corrispondente evento sporadico. PARALLELISMO MISTO Un parallelismo che possiamo chiamare misto si realizza con un sistema dotato di più processori: - ogni processore opera in parallelismo fisico con gli altri processori - ogni processore internamente esegue azioni con parallelismo virtuale (sistemi multitasking distribuiti). Per molte applicazioni viene adottata questa struttura. Cap Sistemi Operativi Real-Time - Lucido 7

9 PARALLELISMO VIRTUALE Torniamo a considerare il caso di un sistema con un unico processore. Purchè il coefficiente di utilizzo della CPU sia U < 1 e lo scheduling temporale sia tale da contenere l'esecuzione di ogni azione all'interno del proprio scopo temporale, l'effetto complessivo osservabile è "equivalente" a quello ottenibile da diversi processori in parallelo. Consideriamo temporalmente equivalenti i sistemi in cui: ogni azione rispetta il vincolo temporale della propria deadline (cioè è temporalmente corretta). Ciò è possibile in quanto le specifiche temporali richieste riguardano solo certe azioni delle elaborazioni ed in particolare quasi sempre riguardano solo l'azione conclusiva di emissione del risultato finale. Cap Sistemi Operativi Real-Time - Lucido 8

10 Esempio di funzioni utilità temporale della risposta e bontà del risultato per descrivere l esecuzione di azioni con scopi temporali sovrapposti. preemption fine 1 fine 2 U2 U1 t Funzioni di utilita' temporale della risposta E1 E2 B1 B2 t Te Te Funzioni di bonta' del risultato Evento E2 - trigger di azione A2 Evento E1 - trigger di azione A1 In questa situazione se A2, triggerata quando è già in corso A1, fosse stata rimandata alla conclusione di A1 (quindi senza preemption), A2 non avrebbe rispettato la sua scadenza. Si noti l importanza di un opportuno scheduling temporale e della preemption. Cap Sistemi Operativi Real-Time - Lucido 9

11 PARALLELISMO VIRTUALE La scala dei tempi rispetto a cui si giudica l'equivalenza temporale è quella degli scopi temporali, più grossolana di quella dei tempi di esecuzione di singole istruzioni. Questa differenza consente la virtualizzazione del parallelismo, intercalando opportunamente le esecuzioni delle azioni concorrenti. Come già rilevato, se il carico di lavoro supera complessivamente il valore unitario è inevitabile dover ricorrere ad un sistema più veloce o con più processori. Il parallelismo virtuale presenta una particolare importanza anche nei sistemi multiprocessore (parallelismo misto ): diventano sempre più economici processori molto più potenti di quanto sarebbe richiesto dalla maggior parte delle singole attività e che quindi sarebbero poco sfruttati da una singola attività; le attività assegnate ad uno stesso processore sono favorite nelle reciproche sincronizzazioni e comunicazioni in termini di semplicità ed efficienza, rispetto a quelle assegnate a processori diversi. Cap Sistemi Operativi Real-Time - Lucido 10

12 MODELLI IMPLEMENTATIVI DI PARALLELISMO VIRTUALE 1 - TIME-DRIVEN = Guidato dal tempo La funzionalità di un sistema di automazione può essere scomposta in un insieme di attività concorrenti (che operano in parallelo tra loro). Ogni attività può essere vista come un processo trasformazionale che riceve in ingresso informazioni dal mondo esterno e (idealmente con continuità) produce in uscita informazioni e comandi da emettere verso il mondo esterno. Nella maggior parte delle applicazioni è pensabile che le informazioni in ingresso al sistema di elaborazione siano ottenute mediante una periodica osservazione (campionamento) di stati continui (analogici) e discreti (digitali). L implementazione di ogni attività può essere realizzata da una porzione di programma (che descrive un azione) da eseguire ad ogni campionamento (quindi ciclicamente) per produrre gli effetti richiesti dall attività. Cap Sistemi Operativi Real-Time - Lucido 11

13 Approccio Time-Driven Con l'approccio time-driven ogni attività viene implementata come un esecuzione, ripetuta ad ogni campionamento, di un istanza di una stessa azione che utilizza i valori catturati in ingresso (Ii) ed eventualmente uno stato interno (Si) e produce un valore di uscita (Oi) e l'eventuale nuovo valore dello stato interno (Si+1). Se si adotta lo stesso periodo di campionamento per tutti gli ingressi, si avrà anche lo stesso periodo di ripetizione ciclica delle azioni che realizzano le varie attività. In questo caso (che è quello più usuale): Il SW applicativo con approccio time-driven consiste in un unico processo da eseguire ciclicamente, che contiene in sequenza le parti di programma che realizzano le azioni delle varie attività. Cap Sistemi Operativi Real-Time - Lucido 12

14 TIME-DRIVEN Per stato interno si intende l insieme di variabili interne i cui valori ricordano ciò che è risultato dalle elaborazioni del ciclo attuale e che deve essere utilizzato nel ciclo prossimo, come è necessario per realizzare funzioni sequenziali (o con una dinamica) e non puramente combinatorie. Ad esempio in un algoritmo che implementa un regolatore PID appartengono allo stato interno la variabile che mantiene il valore precedente della misura, necessaria per il calcolo della derivata, e la variabile che mantiene il valore corrente, da aggiornare ad ogni ciclo, dell integrale. Per le funzioni combinatorie non viene utilizzato uno stato interno, dato che i valori prodotti in uscita dipendono solo da quelli in ingresso in quel momento. Cap Sistemi Operativi Real-Time - Lucido 13

15 Time-driven Esempio di attività combinatoria Emissione di un segnale t_alta (di tipo bit on-off) che indichi se l ingresso temperatura supera un valore di soglia...(* azione elementare *) t_alta = (temperatura > soglia)...(* fine azione elementare *) Esempio di attività sequenziale Emissione del valore di conteggio di impulsi nell ingresso pulse, azzerabile con l ingresso reset Lo stato interno comprende le variabili conteggio e precedente...(* azione elementare *) se pulse and not precedente (* rilievo fronte *) allora conteggio = conteggio+1 se reset allora conteggio = 0 precedente = pulse...(* fine azione elementare *) Cap Sistemi Operativi Real-Time - Lucido 14

16 TIME-DRIVEN Supponiamo che si debbano eseguire le attività concorrenti A, B e C con lo stesso periodo di campionamento. È spontaneo organizzare l'esecuzione delle azioni a, b e c come segue: - all'istante T0 si utilizzano i valori I0 e S0 per eseguire le azioni a(0), b(0), c(0) che producono i valori O0 e S1 - all'istante T1 si utilizzano i valori I1 e S1 per eseguire le azioni a(1), b(1), c(1) che producono i valori O1 e S all'istante Ti si utilizzano i valori Ii e Si per eseguire le azioni a(i), b(i), c(i) che producono i valori Oi e Si+1 Cap Sistemi Operativi Real-Time - Lucido 15

17 TIME-DRIVEN Implementativamente Il programma è costituito dalla sequenza a, b, c Il verificarsi dell'evento temporale "scadenza dell'istante Ti" attiva l'esecuzione della sequenza di operazioni: leggi i valori Ii con campionamento in ingresso esegui il programma, cioè le azioni a(i), b(i), c(i) emetti i valori Oi appena calcolati e aggiorna lo stato interno copiando in S i valori Si+1. Questo approccio, di tipo polling, è detto "guidato dal tempo" (timedriven) perchè tutte le azioni sono eseguite solo in base a eventi temporali ed indipendentemente dal verificarsi di altri eventi interni od esterni, che quindi giocano un ruolo passivo. Cap Sistemi Operativi Real-Time - Lucido 16

18 TIME-DRIVEN Con l approccio time-driven è dominante il concetto di stato e il comportamento è di tipo trasformazionale. Con questo approccio gli eventi esterni giocano un ruolo passivo, cioè non provocano direttamente nessuna azione, ma possono essere rilevati (se necessario) deducendoli dalle differenze di valori degli stati campionati in ingresso, rispetto ai valori campionati nel ciclo precedente. Le eventuali sincronizzazioni di operazioni con eventi esterni sono effettuate secondo la modalità a controllo di programma (v. cap. 5) Lo scheduling delle azioni è statico (off-line), dato che il programmatore, con la stesura del programma, decide la sequenza di esecuzione delle azioni nell ambito del ciclo, e non viene quindi effettuata nessuna preemption. Cap Sistemi Operativi Real-Time - Lucido 17

19 TIME-DRIVEN I pregi non trascurabili di questo approccio lo rendono interessante in molte semplici applicazioni e ne hanno fatto il modello di esecuzione tipico dei PLC -- Semplicità: il supporto "run-time" è costituito da un sistema operativo molto ridotto che si limita alle funzioni di lettura degli ingressi, scrittura delle uscite e alla gestione di un temporizzatore di attivazione ciclica del programma. -- Predicibilità: i tempi di esecuzione molto regolari rendono facile verificare se il fattore di utilizzazione del processore è < 1. U = Σ TEi / Tp Condizione sufficiente perchè si possa adottare un approccio timedriven con un singolo processo ciclico è che sia Σ TEi < Tp dove TEi è il tempo netto di esecuzione dell azione i-esima e Tp è il periodo di ciclo. Cap Sistemi Operativi Real-Time - Lucido 18

20 Time-driven Tempo di risposta Con tale ipotesi, detto Tp il periodo di ripetizione ciclica, il tempo di risposta Tr del sistema di elaborazione soddisfa la relazione: Tp < Tr < 2*Tp Il caso peggiore si ha quando un ingresso cambia subito dopo essere stato campionato all inizio del ciclo i-esimo. Le uscite ottenute alla fine del ciclo i-esimo (cioè dopo il tempo Tp) corrisponderanno ancora al vecchio valore di quell ingresso, mentre solo alla fine del ciclo i+1 (quindi dopo un tempo 2*Tp) le uscite terranno conto del nuovo valore. Il corretto comportamento real-time richiede quindi che sia verificata la relazione: 2*Tp <= TDj dove TDj è la più breve deadline, tra tutte le attività Cap Sistemi Operativi Real-Time - Lucido 19

21 TIME-DRIVEN - Tempi di risposta In realtà la validità della relazione precedente è condizionata al verificarsi di almeno una delle seguenti ipotesi più restrittive. Ipotesi a): le azioni ai, bi, ci, ecc. sono tra loro indipendenti In questo caso nessuna delle azioni utilizza dati prodotti da altre azioni e il tempo di risposta Tr non dipende dall ordine con cui le azioni sono eseguite all interno del ciclo. oppure: Ipotesi b): le azioni ai, bi, ci, ecc. presentano relazioni di dipendenza (cioè alcune producono informazioni usate da altre) rappresentabili con un grafo non ciclico e siano eseguite all interno del ciclo di ripetizione in una sequenza che non viola alcuna dipendenza. Anche in questo caso il tempo di risposta soddisfa la relazione Tr < 2*Tp Cap Sistemi Operativi Real-Time - Lucido 20

22 TIME-DRIVEN - Tempi di risposta Le relazioni di dipendenza tra azioni si hanno quando alcune di esse utilizzano dati prodotti da altre. Possiamo rappresentare queste relazioni come in un grafo orientato di tipo data-flow. In particolare il caso b) richiede che tale grafo sia aciclico e ciò rende possibile individuare (e ciò è compito del progettista) almeno una sequenza tale che all interno del ciclo di esecuzione ogni azione sia eseguita dopo tutte quelle che producono i dati che essa utilizza. A B C G F D E Cap Sistemi Operativi Real-Time - Lucido 21

23 TIME-DRIVEN - Tempi di risposta A B C G F D E Il grafo è aciclico, e quindi esiste almeno una sequenza di azioni che non introduce ritardi ulteriori. Soddisfano a questo requisito ad esempio le sequenze: A-B-D-C-F-G-E D-G-A-F-B-C-E nelle quali ogni azione è preceduta da tutte quelle da cui riceve dati e seguita da tutte quelle cui fornisce dati. Cap Sistemi Operativi Real-Time - Lucido 22

24 TIME-DRIVEN - Tempi di risposta Si noti bene che azioni che presentano un grafo di dipendenze ciclico non costituiscono un errore di progetto, anzi sono la situazione tipica delle reti sequenziali con retroazione e quindi memoria interna (stati interni). Gli stati interni prossimi vengono copiati negli stati interni attuali solo alla fine di ogni ciclo. Gli archi che rappresentano variabili di stato interno da utilizzarsi nel ciclo successivo, non vanno quindi considerati come un vincolo di dipendenza all interno di un ciclo. Semplicemente in questi casi i valori degli ingressi non influenzano solo la prossima uscita entro il tempo 2*Tp, ma anche le uscite in tempi successivi. Cap Sistemi Operativi Real-Time - Lucido 23

25 TIME-DRIVEN Il difetto principale dell approccio ciclico, è costituito dalla notevole rigidità che si può attribuire ai due aspetti seguenti: Tutte le informazioni di ingresso godono dello stesso trattamento temporale, indipendentemente dalla loro urgenza e criticità, obbligando il progettista ad adottare la cadenza imposta dalle attività (Aj) più critiche (2*Tp < TDj) anche per tutte le altre, con uno scarso sfruttamento della CPU. Tutte le attività devono essere ricondotte alla forma di ripetizione ciclica degli stessi calcoli. Questo rende talvolta macchinoso realizzare costrutti di controllo come quelli dei linguaggi di alto livello orientati al software. Inoltre si nota facilmente come i principi di alta coesione e basso accoppiamento, caratteristici di una buona modularità, siano decisamente disattesi, almeno nella forma. Cap Sistemi Operativi Real-Time - Lucido 24

26 TIME-DRIVEN In realtà con questa tecnica di programmazione ciclica si assume, come accennato, una visione più vicina alle strutture hardware, di impostazione "dichiarativa", piuttosto che alle sequenze software generalmente orientate al paradigma "imperativo" (v ). Questo aspetto è considerabile come positivo in certi settori applicativi, tipicamente di semplici automazioni, e per le attitudini dei relativi tecnici e progettisti, come l'evoluzione dei PLC (Programmable Logic Controller) ha dimostrato. Altre considerazioni sull'approccio time-driven si trovano nel capitolo dedicato ai PLC. Cap Sistemi Operativi Real-Time - Lucido 25

27 Multitasking Event-Driven Le azioni sono eseguite ognuna da un processo (task o thread) che viene attivato da eventi esterni o da eventi temporali. Gli eventi assumono quindi un ruolo attivo Poichè agli eventi sono associate delle informazioni (dati) questo approccio si può chiamare anche data-driven Le sincronizzazioni con gli eventi sono tipicamente basate sul meccanismo dell interrupt (v. cap. 5) Evento -> sync 1 -> ISR -> sync 2 -> Processo Per il rispetto di vincoli temporali occorre una politica di scheduling Questo approccio è più complesso ma anche più generale, e può adottare al suo interno anche task con esecuzione time-driven. Cap Sistemi Operativi Real-Time - Lucido 26

28 Un semplice esempio Per confrontare le diverse forme che assume la stessa funzionalità realizzata secondo le diverse tecniche implementative time-driven e event-driven, presentiamo un semplicissimo esempio. Supponiamo di voler realizzare la funzione di temporizzazione non retriggerable one-shot presentata come Temporizzazione a durata nel cap.6, cioè dopo ogni fronte di salita dell ingresso IN vogliamo generare in uscita un impulso di durata DT, come descritto dalle seguenti forme d onda. IN OUT DT Cap Sistemi Operativi Real-Time - Lucido 27

29 VERSIONE TIME-DRIVEN (ciclica trasformazionale) Supponiamo di usare le variabili PREV (variabile di stato interno) per rappresentare il valore dell ingresso nel campionamento precedente, PRES per il valore di stato appena campionato. Queste variabili serviranno per dedurre gli eventi. TIMER.START, che può essere vista come un registro di comando del timer, ne lancia la temporizzazione (non retriggerabile), TIMER.OUT rappresenta il registro di stato del timer che ne fornisce il valore in uscita (TRUE durante il tempo di durata). La sequenza è ripetuta ciclicamente con periodo PERIOD. EVERY PERIOD DO PREV = PRES PRES = IN TIMER.START = PRES AND NOT PREV OUT = TIMER.OUT END Cap Sistemi Operativi Real-Time - Lucido 28

30 Rappresentazione a struttura circuitale tipo data-flow Si noti la corrispondenza con una descrizione con paradigma dichiarativo, di tipo hardware. INPUT CYCLE D Q PRES D Q PREV NOT OUT OUTPUT CK CK AND TIMER START Cap Sistemi Operativi Real-Time - Lucido 29

31 VERSIONE EVENT-DRIVEN (REATTIVA) Riportato nel seguito codificato in un linguaggio pseudo-c, nella forma (improbabile ma esemplificativa) a controllo di programma nella forma ad interrupt e primitive di Sistema Operativo. Event Driven a Controllo di programma La funzione input(in) riporta il valore LOW o HIGH dell ingresso IN. TIMER vale TRUE durante la temporizzazione di durata DT do { while (input(in) == LOW) { } // ciclo attesa StartTimer(DT); output(out, HIGH); while (TIMER) { } // ciclo attesa output(out, LOW); while(input(in) == HIGH) { } } while (FOREVER); // ciclo attesa Cap Sistemi Operativi Real-Time - Lucido 30

32 Event Driven con primitive (interrupt) Si suppone che i fronti di salita e di discesa del segnale di ingresso generino delle richieste di interrupt che a loro volta generano (sincronizzazione di secondo livello) gli eventi fronte_salita e fronte_discesa. do { wait (fronte_salita) output(out, HIGH); wait_time (DT) output(out, LOW); wait (fronte_discesa) } while (FOREVER); Cap Sistemi Operativi Real-Time - Lucido 31

33 Rappresentazione a sequenza Questo approccio, che segue un paradigma imperativo, presenta una facile corrispondenza con descrizioni come automa o come SFC. AUTOMA A STATI 0 OUT = LOW INPUT HIGH INPUT LOW 1 OUT = HIGH 2 TIME EXPIRES OUT = LOW Cap Sistemi Operativi Real-Time - Lucido 32

34 Rappresentazione a sequenza (*) SFC (GRAFCET) IN = H IG H START TIM ER TRUE OUT HIGH DT EXPIRES OUT LOW IN = LO W Cap Sistemi Operativi Real-Time - Lucido 33

35 Considerazioni sulle tecniche presentate L'approccio guidato dagli eventi costituisce il caso più generale (considerando eventi temporali, esterni e interni) può supportare al suo interno anche sottoinsiemi di attività impostate secondo gli schemi precedenti (processi time-driven), fornendo quindi la massima flessibilità progettuale anche se a costo di una problematica molto più articolata e complessa. In particolare un'applicazione complessa potrà comprendere: un sottoinsieme di attività cicliche di controllo e supervisione (trasformazionali) i cui vincoli temporali consistono sostanzialmente in un attivazione ciclica regolare, adatte ad una gestione di tipo time-driven; alcune azioni di tipo reattivo a eventi sporadici e con vincoli temporali sui tempi di risposta, per cui è conveniente una gestione event-driven; attività di sottofondo senza particolari vincoli temporali che utilizzano in modo execution-driven i tempi lasciati liberi dalle attività precedenti. Cap Sistemi Operativi Real-Time - Lucido 34