2009-12-07 10 views
19

Per favore correggimi se ho torto. Qui è la mia comprensione di segnali:Come fa un processo a sapere che ha ricevuto un segnale

Per quanto ne so, la generazione del segnale e la consegna del segnale sono 2 diversi cose. Per generare un segnale, il sistema operativo imposta semplicemente un bit in un bitarray gestito nel Controllo processo Block (PCB) del processo. Ogni bit corrisponde a un particolare segnale, e quando un bit è impostato, significa che il segnale corrispondente al bit è in sospeso.

consegna: Prima di trasferire il controllo indietro a un processo in modalità utente, il kernel controlla sempre i pendenti segnali per questo processo. Questo controllo deve avvenire nello spazio Kernel perché alcuni segnali non possono mai essere ignorati da un processo - vale a dire SIGSTOP e SIGKILL.

Questo significa che i segnali possono essere inviati a un processo solo quando il kernel sta pianificando quel processo, allocandolo CPU? Un processo può ricevere un segnale quando è effettivamente in esecuzione sulla CPU? Se è così, come è possibile, cioè come il processo arriva a sapere che un segnale è in sospeso per esso (poiché è in esecuzione in modalità Utente e non può accedere al PCB)

Dire che c'è una macchina multiprocessore e quindi c'è reale parallelismo cioè più processi vengono eseguiti contemporaneamente. Il processo P1 è in esecuzione su cpu 1 e il processo P2 sta eseguendo su cpu2 e ora il processo P2 (con privilegi sufficienti) invia un segnale per elaborare P1. Questo segnale verrà consegnato a P1 in questo momento o verrà consegnato dopo che P1 ha ceduto la CPU per qualche motivo ed è nuovamente riprogrammato in un secondo momento dal Kernel e quindi questo segnale viene consegnato per elaborare P1.

Si prega di non dire questa domanda dipende dall'implementazione. Se si trova che la risposta corretta è definita dall'implementazione, cerco risposte in Linux, FreeBSD o qualsiasi piattaforma * nix di cui si abbia conoscenza.

Grazie mille per il vostro aiuto e la pazienza :)

saluti

Lali

risposta

12

La risposta è implementazione :) dipendente. Su Mac OS X (e FreeBSD), i segnali vengono gestiti in modo asincrono: il kernel trova un thread che non blocca il segnale e imposta un flag Asynchronous System Trap su quel thread. La volta successiva che il kernel pianifica quel thread, gestisce il trap (abbandonando il processo, ignorando il trap o invocando il gestore di segnali nello spazio utente come appropriato) invece di organizzare la consueta continuazione del thread nello spazio utente.

Su Solaris, l'implementazione è in qualche modo simile, sebbene offra anche segnali sincroni basati su trap hardware: i segnali sincroni vengono inviati al thread che ha generato il trap, mentre i segnali asincroni funzionano come descritto sopra.

Linux does something similar a Solaris (non sono sicuro di come la conclusione in tale riferimento derivi dalla discussione, ma è la discussione che è utile).

Posix.4 definisce anche i segnali in tempo reale, ma non ho lavorato con quelli.

+0

Ciò significa che il segnale viene consegnato solo quando è pianificato quel processo? Cosa succede se il processo è impegnativo per la CPU e attualmente è in esecuzione su cpu1 di una macchina con 2 cpus e la pianificazione non è di tipo preventivo, quindi il processo non riceverà alcun segnale anche se il processo in esecuzione su cpu2 invia un segnale (come processo su cpu1 non cede mai la cpu1)? È ? – ghayalcoder

+0

@Graham: Perché il # 2 non dovrebbe mai essere eseguito su una macchina core 2+? – SiegeX

+0

Scusa @SiegeX, sei corretto, quindi ho cancellato il mio commento. Mi sono confuso quando ho cercato di analizzare la frase di @Iali. –

3

La risposta breve è - sì, il processo ottiene la conoscenza di un segnale solo sulla successiva ora di CPU programmata.

Come sapere che il processo ha ricevuto un segnale - può chiamare sigprocmask (2).

0

Il processo P1 è in esecuzione su cpu 1 e il processo P2 è in esecuzione su cpu2 e ora il processo P2 (con privilegi sufficienti) invia un segnale per elaborare P1. Questo segnale verrà consegnato a P1 in questo momento o verrà consegnato dopo che P1 ha ceduto la CPU per qualche motivo ed è nuovamente riprogrammato in un secondo momento dal Kernel e quindi questo segnale viene consegnato per elaborare P1.

Per quanto ne so sull'esecuzione degli ultimi kernel Linux di P1 può essere messo in pausa quando P2 emette il segnale e il segnale verrà consegnato immediatamente. Può essere vero solo per i segnali in tempo reale

0

Se ricordo correttamente, il bit di arrivo dell'interrupt è stato controllato durante l'ultimo stato T di un'istruzione 8085. Quindi deve esserci un modo per generare un vero interrupt all'arrivo del segnale, oppure deve esserci una slice di codice (costante?) Prima che il bit del segnale sia controllato.

Sfortunatamente, sembra che l'unico modo per rispondere ad alcune domande relative al comportamento del kernel sia di passare attraverso il codice sorgente, perché sono così "dipendenti dall'implementazione". La programmazione del computer è davvero a dir poco molestia: che professione scegliere!

Cerca solo di essere perfetto, e spero che questo sito web ti sia d'aiuto.

Problemi correlati