Riguardo agli interrupt e ai timer del sistema. Perché a volte i programmi vengono ancora eseguiti quando il sistema operativo richiede di terminare o continuare a funzionare?

3

Sto leggendo (appena iniziato) "Concetti dei sistemi operativi" di Silberschatz, Galvin e Gagner e qualcosa ha richiamato la mia attenzione durante la lettura di un manuale di base su "timer" (1.5.2 sul libro).

Dice:

As long as the counter is positive, control is returned to the user program. When the counter becomes negative, the operating system terminates the program for exceeding the assigned time limit.

Ora, finalmente so come, ad esempio, Windows sa quando spuntare quel messaggio errore chiedendo se si desidera chiudere un programma che sembra bloccato / bloccato o tenerlo in esecuzione

La mia domanda è: se il sistema operativo termina o blocca il programma prima di chiedere l'input, come mai a volte compare la finestra e se aspetti che il programma a volte continui a funzionare e cesserà di apparire come congelato o riattaccato? (Buon esempio: se fai ripetutamente clic sull'icona della barra delle applicazioni di un gioco durante il caricamento).

    
posta Emannuel Weg 10.06.2018 - 07:09
fonte

1 risposta

2

@ I commenti di VisualMelon l'hanno inchiodato, ma per elaborare un po 'in forma di risposta:

Silberschatz, Galvin e Gagner stanno parlando di come un kernel del sistema operativo può gestire i processi: potrebbe impostare un limite di risorse rigoroso sul tempo di CPU per un processo e uccidere il processo (non solo segnalare che è non risponde) se supera questo limite.

Normalmente le persone non lo fanno, perché i processi di uccisione arbitraria di solito sono una cattiva idea. Tuttavia, è supportato da, ad esempio, il comando ulimit -t di Linux

di Linux.

Il messaggio di errore di Windows che dice che un programma sembra essere congelato sta funzionando a un livello molto più alto rispetto al limite di tempo della CPU di basso livello che Silberschatz, Galvin e Gagner stanno discutendo. La GUI di Windows funziona con messaggi : i messaggi vengono inviati regolarmente alle applicazioni in esecuzione, per gestire qualsiasi cosa, dalla notifica dell'applicazione di eventi mouse e tastiera alla richiesta che un'applicazione ridisegna il contenuto dello schermo dopo un aggiornamento. Al suo centro, quindi, un'applicazione GUI di Windows ha in genere un ciclo while che legge i messaggi dalla coda dei messaggi e li elabora ciascuno.

I problemi sorgono se l'applicazione impiega troppo tempo per elaborare un messaggio (perché è bloccato in attesa di file o I / O di rete, o perché ha avviato una lunga attività della CPU o perché è entrato in un ciclo infinito). Quando ciò accade, l'applicazione non sta ricevendo ed elaborando nuovi messaggi, quindi non può rispondere all'input o persino ridisegnare il contenuto dello schermo. Questa è una brutta esperienza utente, quindi per renderlo meno cattivo, Windows rileverà quando le applicazioni non controllano le code dei messaggi e visualizzeranno il messaggio che hai menzionato, chiedendo se vuoi uccidere l'applicazione.

Naturalmente, Windows in realtà non sa se l'applicazione è veramente bloccata (ad esempio, loop infinito o deadlock) o se sta solo facendo qualcosa di più del previsto e riprenderà a elaborare i messaggi a breve. (Windows non può sapere - questo è il problema di interruzione .) Ecco perché a volte appaiono le applicazioni per ripristinare dopo Windows dice che sono congelati.

A causa di questo problema, le applicazioni Windows ben scritte sposteranno qualsiasi attività potenzialmente lunga in background thread in modo che possano continuare a pompare la coda dei messaggi e quindi rimanere reattivi, ma assicurandosi che ciò avvenga ovunque è necessario è più facile dire di fatto.

    
risposta data 15.06.2018 - 18:27
fonte

Leggi altre domande sui tag