1 SYNCHRONOUS/ REACTIVE PROGRAMMING In Sistemi Software Concorrenti.

Presentazione sul tema: "1 SYNCHRONOUS/ REACTIVE PROGRAMMING In Sistemi Software Concorrenti."— Transcript della presentazione:

1 1 SYNCHRONOUS/ REACTIVE PROGRAMMING In Sistemi Software Concorrenti

2 2 Systemi Software Concorrenti I sistemi software son costituiti da Componenti che reagiscono a richieste esterne di servizio Ogni componente è in grado di servire più richieste concorrentemente La concorrenza può essere vista in modi diversi Competitive: le richieste concorrenti competono su una risorsa per la propria esecuzione Cooperative: esse collaborano per soddisfare una singola richiesta di livello più alto

3 3 Systemi Software Concorrenti Competitive concurrency: mantiene l’illusione del time sharing permettendo che una singola richiesta di servizio resti invisibile ad altre richieste da essa scorrelate ed attive simultaneamente. Si verifica quando una componente può eseguire due o più servizi scorrelati e generati all’esterno della componente stessa

4 4 Systemi Software Concorrenti Cooperative concurrency: eaumenta le performance nel soddisfare una rchiesta o semplifica il coordinamento di più eventi che concorrono al completamento della stessa. Opera all’interno di una stessa componente e riduce la latenza della richiesta stessa

5 5 Systemi Software Concorrenti Internal concurrency: la concorrenza controllata esplicitamente da una singola componente External concurrency: ogni altro tipo di concorrenza

6 6 Software Architecture “The structure of the components of a program/ system, their interrelationships, and principles and guidelines governing their design and evolution over time [D. Garlan D. E. Perry]” Composta da a shared repertory of methods, techniques, patterns and idioms for structuring complex software systems

7 7 Event-Driven programming Evento come un’eccezione un evento è una condizione (hardware) segnalata al contrario di un eccezione un evento rappresenta una condizione normale La tecnica usata per per gestire eventi è detta event- based o event-driven programming, Nella programmazione event-driven (ad eventi) non si ha un flusso di controllo normale ma sostanzialmente solo event handlers

8 8 Event-Driven programming L’idea base è quella di gestire una coda di eventi in modo tale che quando l’ambiente (mondo esterno al programma) è operativo genera eventi che vengono inseriti nella coda Il programma cicla all’interno di un outermost (switch) statement (o usa tecniche equivalenti) in cui si chiede se vi sono eventi in coda, in caso affermativo li preleva e li gestisce.

9 9 Event-Driven programming Event-driven programming è quindi uno stile di programmazione in cui il programma è pilotato (driven) da eventi esterni. I programmi Event-driven sono composti da piccole porzioni di codice dette: event handlers, attivati in risposta a eventi esterni e da un event dispatcher, che attiva gli event handlers, tramite l’uso di event queue che memorizzano gli eventi non ancora processati.

10 10 Event-Driven programming cont. Ne consegue che, al contrario dei programmi tradizionali che seguono un proprio flusso di controllo (own control flow pattern) e solo raramente cambiano direzione ai punti di salto (branch points), il flusso di controllo dei programmi a eventi (event-driven) è sostanzialmente pilotato dagli eventi esterni. Un event handler è una porzione di codice eseguita quando si verifica un evento.

11 11 Event-Driven programming cont. In molti casi gli event handlers possono attivare (trigger) a loro volta nuovi eventi, provocando una cascata di eventi. Event-driven programming rinforza flessibilità e asincronia e tende ad essere praticamente modeless. Le graphical user interface sono solitamente programmate in stile event-driven. Gli Operating Systems costituiscono un altro esempio di event-driven programs.

12 12 Interrupt-Driven programming The style of programming where the program is not in control all the time but rather responds to interrupts or signals in order to get started. At the lowest level, interrupt handlers act as direct event handlers for hardware events, with the CPU hardware performing the role of the dispatcher.

13 13 Interrupt-Driven programming Lo stile di programmazione in cui il programma non ha il controllo in modo continuo ma responde ad interrupts, cioè a segnali che ne risvegliano l’esecuzione. Al livello più basso, gli interrupt handlers agiscono come gestori diretti di eventi hardware, mentre la CPU gioca il ruolo del dispatcher.

14 14 Sistemi Reattivi (Reactive Systems) Un sistema reattivo è un sistema event-driven che interagisce continuamente con l’ ambiente (environment) reagendo agli stimoli che da esso gli pervengono. Si assume che i sistemi reattivi: eseguano con una velocità mai sopraffatta da quella dell’ambiente. usualmente non terminino mai e quindi non siano facilmente caratterizzabili da semplici funzioni che partendo da uno stato iniziale li portino ad uno stato finale.

15 15 Sistemi Reattivi (Cont.) Un sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints) nella gestione degli eventi. Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

16 16 Event-Driven Reactive systems Un reactive system è anche event-driven inoltre un sistema interrupt-driven è anche event-driven reactive | interrupt-driven | ==> event-driven systems o anche | signal-driven | system |

17 17 Sistemi Reattivi (Cont.) Un sistema real-time è un sistema reattivo che deve rispettare vincoli temporali (timing constraints). Il termine reactive è più specifico di event- driven (piuttosto overloaded in letteratura) ma è più generale di soft real-time e near real- time: poiché esso non si riferisce a vincoli temporali da rispettare in real-time. I sistemi reattivi più semplici vengono spesso programmati come macchine a stati finiti (automi).

18 18 Sistemi Reattivi (Cont.) Le architetture software sincrone sono state esplicitamente introdotte per la programmazione dei sistemi reattivi. I sistemi risultanti includono architetture data-flow e dichiarative ed anche quelle derivate dai tradizionali linguaggi imperativi.

19 19 Sistemi Reattivi (Cont.) L’ ipotesi di sincronia (synchrony hypothesis) assume che tutte le computazioni avvengano in passi atomici discreti durante i quali il tempo viene ignorato (eseguono in tempo nullo) Il tempo avanza solo quando non vi è codice eligible for execution. Durante un singolo step tutti gli output avvengono allo stesso istante come tutti gli input dello step:cioè output e input sono mutuamente sincroni il concetto di tempo continuo è sostituito da una serie ordinata di passi (step) discreti tra i quali avvengono canbi discreti nello stato globale. Il codice eseguito in ogni passo è detto una reazione (reaction)

20 20 Ipotesi di sincronia (Cont.) L’ ipotesi di sincronia permette di gestire la concorrenza interna di tipo cooperativo in modo deterministico. Gli eventi concorrenti asincroni si manifestano solo nell’ambito di global state ‘shapshots’ Nessuna sezione critica esplicita occorre nel codice sorgente né in forma di monitor od oggetti concorrenti tutto il codice può essere pensato interno a sezioni critiche implicite eseguite con lo stile di programmazione dei guarded command

21 21 Linguaggi sincroni I linguaggi syncroni/reattivi si focalizzano sulla concorrenza interna di tipo cooperativo comunemente presente in driver e controller essi incapsulano nella compilazione tutta la concorrenza interna cooperativa producendo una singola macchina a stati finiti che gestisce tutte le attività I principali sono Meta/NPL di ISIS [Marzullo & Wood] Estrel e Reactive C