Domanda su interrupt

[Zazzu]

Scusa non mi sono spiegato bene, quello che mi stai dicendo tu è cosa fare per evitare che succeda quello che ho descritto, quello che volevo sapere io invece era il comportamento del processore nel caso in cui il codice sia stato scritto senza le accortezze da te elencate.

[xyz]

L'esempio banale non esiste perché non è banale. Dipende cosa stai utilizzando come compilatore, librerie o se si è sotto un RTOS con una propria API di programmazione.

Le cose con ARM funzionano in maniera diversa rispetto al vecchio x86 col mascheramento degli interrupt. ARM ha delle istruzioni assembler studiate apposta per gestire le operazioni atomiche in modo più efficiente.

http://infocenter.arm.com/help/index.js ... 02s01.html

Nelle CMSIS esistono le macro per richiamare le istruzioni assembler precedenti in C:

http://infocenter.arm.com/help/index.js ... EJCHB.html

Senza le operazioni atomiche qualsiasi programma concorrente potrebbe potenzialmente accedere a dati condivisi corrotti.

[rugweri]

Scusa non mi sono spiegato bene, quello che mi stai dicendo tu è cosa fare per evitare che succeda quello che ho descritto, quello che volevo sapere io invece era il comportamento del processore nel caso in cui il codice sia stato scritto senza le accortezze da te elencate.

Aspetta, ora sono io che non capisco:

- Vuoi sapere cosa fa il processore se, durante l'esecuzione di un interrupt, ne viene sollevato un altro?

La risposta risiede nel meccanismo di gestione degli interrupt: di solito, tra periferiche e processore c'è un modulo apposito che si occupa di questo.

-----------------------------------------------------------------------------------------------------------------------

- Vuoi sapere cosa permette di fare la gestione dei segnali a livello di SO?

Questo dipende da come è fatto il SO. Nei sistemi UNIX-like, per esempio, ci sono una quarantina di segnali (definiti come costanti simboliche C nella libreria signal.h) cui un'apposita funzione (dal molto fantasioso nome di signal) permette di associare un'altra funzione, che sarà eseguita ogni volta che il segnale giungerà al processo.
Qui puoi trovare una lista dei segnali UNIX, leggendo la quale devi comunque tenere presente che alcuni SO ne hanno anche altri (e forse alcuni SO ne hanno di meno... non me ne vengono in mente, ma sicuramente sistemi del genere esistono).

Il vantaggio di una cosa del genere è che, in linea di principio, nella funzione di gestione potresti banalmente inserire una serie di procedure per far "ricominciare" il tuo programma da dove vuoi (NON UNA GOTO).
Ovviamente in realtà non sarà così lineare... ma partire da un'idea del genere non è male.

Lo svantaggio è che (guarda un po') i segnali sono asincroni, e quindi potrebbero far danno: metti che uno di loro arrivi mentre stai facendo una malloc (la quale, se non lo sapessi, di norma tiene una linked list relativa alla memoria allocata), per esempio.
In merito, la Single UNIX Specification contiene una lista di re-entrant routines, e cioè funzioni che garantiscono il corretto funzionamento anche in caso di segnali "molesti".

Naturalmente, a questo potresti poi applicare altre idee legate alle possibilità del tuo SO... sta a te capire fino a che punto vuoi spingerti.
A mio avviso, comunque, non sarebbe male dotarsi di un testo che spieghi cosa davvero può fare la tua dotazione: come ha evidenziato XYZ, sistemi hardware/software diversi hanno possibilità diverse e meccanismi completamente diversi per gestire le varie situazioni.

[Zazzu]

Va bene grazie ad entrambi, mi avete riempito di sigle che passerò le prossime settimane a studiare