# data[].attributes.body
Possibili cause di errore e interferenza che possono violare la liveness:

errori di sincronizzazione;

errori con i segnali tra processi cooperanti;

fallimenti di un processo: si attende un segnale da un altro processo che è andato in crash;

livelock: continuo tentativo di una azione che fallirà sempre;

lockout: chiamata di una operazione che non sarà mai disponibile;

esaurimento di una risorsa necessaria per evolvere.

# data[].attributes.body
Liveness
E' una proprietà che riguarda le attività, cioè i processi, in merito alla loro «esecuzione ed evoluzione»

Si deve garantire che il processo che avanza porterà a termine in modo corretto il proprio lavoro, cioè “somethinggoodeventuallyhappens”

A tal fine i meccanismi di sincronizzazione devono fare in modo che un processo:

non aspetti “indeterminatamente” che una risorsa venga rilasciata

che tutti i processi si “blocchino” in attesa di eventi che non possono verificarsi

è la proprietà che esclude situazioni di deadlock

# data[].attributes.headline
Proprietà non funzionali: safety e liveness

# data[].attributes.subject
Proprietà non funzionali: safety e liveness

# data[].attributes.body
Safety

La safety è una proprietà che riguarda lo stato delle risorse

con questa proprietà si intende una condizione che deve sempre verificarsi per il buon fine dell’esecuzione del processo oppure una condizione di pericolo che non si deve mai verificare per la sicurezza del sistema.

se un sistema avanza, questo va “nella direzione voluta” senza eseguire azioni indesiderate, cioè “nothingbadeverhappens”

# data[].attributes.body
Blocco critico o deadlock

# data[].attributes.body
Starvation e deadlock

Un errata sincronizzazione può portare:

•fallimento delle elaborazioni

genera situazioni di incoerenza dei dati

a situazioni di blocco dei processi

Abbiamo due situazioni possibili:

starvation: blocco individuale

deadlock : stallo o blocco multiplo

# data[].attributes.body
La regola di mutua esclusione stabilisce che in ogni istante una risorsa o è libera oppure è assegnata a uno e un solo processo

In particolare per avere la mutua esclusione devono essere soddisfatte le seguenti quattro condizioni:

1. nessuna coppia di processi può trovarsi simultaneamente nella sezione critica

2. l’accesso alla regione critica non deve essere regolato da alcuna assunzione temporale o dal numero di CPU

3. nessun processo che sta eseguendo codice al di fuori della regione critica può bloccare un processo interessato a entrarvi

4. nessun processo deve attendere indefinitamente per poter accedere alla regione critica

# data[].attributes.body
Il consumatore andrebbe a prelevare un dato non ancora prodotto

# data[].attributes.body
A causa dello scadere del timeslice un processore potrebbe eseguire nel tempo le istruzioni in questa sequenza:

# data[].attributes.body
Errore causato dalla interrompibilità delle operazioni
Due processi P1 e P2 condividono una regione di memoria

Il produttore genera un numero e lo inserisce nella prima posizione libera di un vettore vet_dati[x]

Il consumatore legge l’ultimo dato inserito azzerando il contenuto della cella.

# data[].attributes.body
Nel modello a memoria condivisa le risorse comuni condivise saranno le variabili globali che verranno utilizzate dai diversi processi per scambiarsi le informazioni

# data[].attributes.body
Prima di elencarle è necessario introdurre il concetto di dominio e di rango di una procedura, che si ottiene dall’unione dei domini e ranghi delle singole istruzioni

# data[].attributes.body
Prima di procedere con lo studio dei meccanismi che permettono di realizzare la mutua esclusione è necessario introdurre alcune definizioni e rivedere quelle incontrate sino a questo punto della trattazione per completarne la formalizzazione.

# data[].attributes.body
Riassumiamo le caratteristiche degli errori dipendenti dal tempo:

irriproducibili

indeterminati

latenti

difficili da verificare e testare

# data[].attributes.body
La programmazione concorrente nasconde maggiori insidie della normale programmazione monoprogrammata

Introduce la possibilità di commettere errori dipendenti dal tempo

Le normali tecniche di debugging non sono efficaci  oltre alla correttezza logica ai programmi è anche richiesta la correttezza temporale

È molto diverso effettuare il testing di un programma concorrente rispetto a uno sequenziale:

il programma sequenziale produce diversi risultati ma solo in funzione di dati di input diversi e il programmatore,

nei programmi concorrenti, oltre agli errori sequenziali, sono possibili gli errori legati ai tempi di esecuzione e di schedulazione nella CPU che non si possono determinare ed eliminare tramite

La maggior parte dei sistemi concorrenti ha a necessità di sfruttare al massimo le potenzialità del sistema di calcolo richiede di conciliare l’affidabilità del software all’esigenza di massimizzare l’efficienza di elaborazione (soprattutto nei sistemi a hard real time  dove è assolutamente indispensabile il rispetto delle deadlines temporali - timing constraint)

# data[].attributes.body
- le tipologie di errori nei processi paralleli

- le motivazioni della sincronizzazione

- le proprietà richieste ai programmi concorrenti

# data[].attributes.headline
LA SINCRONIZZAZIONE TRA PROCESSI (Lezione 4)

# data[].attributes.subject
LA SINCRONIZZAZIONE TRA PROCESSI (Lezione 4)