Interruptions software

Le
Papouille
Bonjour,

Il est dit que les interruptions peuvent survenir à n'importe quel
moment, imprévisible, au cours de l'exécution d'un thread.

Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.

je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.

En effet, ce sont des instructions assembleur "INT XX" où XX est le nº
du vecteur d'interruption. Donc c'est bien un thread en cours
d'exécution, celui qui contient l'instruction assembleur "INT xx", qui
provoque l'interruption software.

Il n'y a rien d'impévisible, là

En quoi les interruptions "software" font-elles partie des "interruptions" ?

(Exemple :interruptions DPC, interruptions APC etc)

A bientôt

Papouille
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 4
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
antoine
Le #17864711
"Papouille" news:4920517f$0$28418$
Bonjour,

Il est dit que les interruptions peuvent survenir à n'importe quel moment,
imprévisible, au cours de l'exécution d'un thread.

Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.

je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.

En effet, ce sont des instructions assembleur "INT XX" où XX est le nº du
vecteur d'interruption. Donc c'est bien un thread en cours d'exécution,
celui qui contient l'instruction assembleur "INT xx", qui provoque
l'interruption software.

Il n'y a rien d'impévisible, là...

En quoi les interruptions "software" font-elles partie des "interruptions"
?



Les int. software sont expliquée dans le livre " Undocumented Windows NT" de
1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56
Papouille
Le #17865941
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT" de
1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56



Merci, mais ma question ne porte pas sur ce qu'est une interruption
software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était
une interruption software) mais sur la raison pour laquelle on l'appelle
"interruption" alors que son action se situe à un moment totalement
prévisible, à la différence des interruptions hardware par exemple...

Merci et à bientôt

Papouille
antoine
Le #17870281
"Papouille" news:492077da$0$29787$
antoine a écrit :
Les int. software sont expliquée dans le livre " Undocumented Windows NT"
de 1999
Des extraits :
"http://www.windowsitlibrary.com/Documents/Book.cfm?DocumentID56



Merci, mais ma question ne porte pas sur ce qu'est une interruption
software (j'ai d'ailleurs expliqué dans le post de départ ce qu'était une
interruption software) mais sur la raison pour laquelle on l'appelle
"interruption"



"interruption", car l'exécution du code est bien interrompue, pour exécuter
comme il est dit "the handler routine specified in the interrupt descriptor
table entry"
Vincent Burel
Le #17870951
"Papouille" news:4920517f$0$28418$
Bonjour,

Il est dit que les interruptions peuvent survenir à n'importe quel
moment, imprévisible, au cours de l'exécution d'un thread.

Dans les interruptions, on distingue les interruptions hardware et les
interruptions software.

je ne comprends pas en quoi l'on peut dire que les interruptions
"software" peuvent survenir à n'importe quel moment.

En effet, ce sont des instructions assembleur "INT XX" où XX est le nº
du vecteur d'interruption. Donc c'est bien un thread en cours
d'exécution, celui qui contient l'instruction assembleur "INT xx", qui
provoque l'interruption software.

Il n'y a rien d'impévisible, là...

En quoi les interruptions "software" font-elles partie des "interruptions"


?

(Exemple :interruptions DPC, interruptions APC... etc)



Ben, je dirais que les interruptions software sont le fait du logiciel ou
viennent directement du processor. (un timer, le scheduler qui distribue la
resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les
interruptions hardware sont le fait d'élément extérieur au processeur
(arrivé de données sur un port, réponse de controleurs etc... ).

VB
Papouille
Le #17875171
antoine a écrit :
"interruption", car l'exécution du code est bien interrompue, pour exécuter
comme il est dit "the handler routine specified in the interrupt descriptor
table entry"



Oui, le code est interrompu. Mais les exceptions interrompent aussi le
code, et pourtant ce ne sont pas des interruptions.

Les interruptions sont imprévisibles.

En quoi les interruptions *software* le sont ?
Papouille
Le #17875161
> Ben, je dirais que les interruptions software sont le fait du logiciel ou
viennent directement du processor. (un timer, le scheduler qui distribue la
resource CPU aux thread, une division par zéro, le mode debug etc... ) . Les
interruptions hardware sont le fait d'élément extérieur au processeur
(arrivé de données sur un port, réponse de controleurs etc... ).

VB





Oui, mais les exceptions (division par zéro, page default) ne sont pas
des interruptions, dans la mesure où en répétant le même code dans les
même conditions, l'exception se répète aussi.

Ce qui n'est pas le cas des interruptions - software comme hardware -
qui sont imprévisibles.

En quoi une interruption software est-elle imprévisible puisqu'il s'agit
de soft (de code assembleur) et non pas de hardware ?
Vincent Burel
Le #17879081
"Papouille" news:4921bb9c$0$7770$

> Ben, je dirais que les interruptions software sont le fait du logiciel


ou
> viennent directement du processor. (un timer, le scheduler qui distribue


la
> resource CPU aux thread, une division par zéro, le mode debug etc... ) .


Les
> interruptions hardware sont le fait d'élément extérieur au processeur
> (arrivé de données sur un port, réponse de controleurs etc... ).
>
> VB
>
>

Oui, mais les exceptions (division par zéro, page default) ne sont pas
des interruptions, dans la mesure où en répétant le même code dans les
même conditions, l'exception se répète aussi.

Ce qui n'est pas le cas des interruptions - software comme hardware -
qui sont imprévisibles.

En quoi une interruption software est-elle imprévisible puisqu'il s'agit
de soft (de code assembleur) et non pas de hardware ?



Une interruption, comme sont nom l'indique est qqc qui va venir interrompre
le cours normal des choses.
La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne
change pas la nature du phénomène : l'interruption du cours du programme
principale. Après il faut entendre ce qu'on entend par "prévisible" , quand
on attend une interruption d'un controler disk en réponse à une requète, on
sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est
pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire
facilement, de manière déterministe si quand un zéro va apparaitre sur un
diviseur.

VB
Papouille
Le #17885361
Vincent Burel a écrit :

Une interruption, comme sont nom l'indique est qqc qui va venir interrompre
le cours normal des choses.
La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption ne
change pas la nature du phénomène : l'interruption du cours du programme
principale. Après il faut entendre ce qu'on entend par "prévisible" , quand
on attend une interruption d'un controler disk en réponse à une requète, on
sait qu'il va y avoir une interruption, mais on ne sait pas quand. C'est
pareil pour la division par zero, y'a des calcul où l'on ne sait pas dire
facilement, de manière déterministe si quand un zéro va apparaitre sur un
diviseur.

VB



Oui, mais non, nous ne sommes pas sur la même longueur d'onde...

La prévisibilité ou non EST la définition de l'interruption versus
l'exception.

Les interruptions sont dites asynchrones, les exceptions sont
synchrones, et ces dernières sont provoquées par l'exécution d'une
instruction assembleur (page fault, division par zéro..).

Ce qui est prévisible n'est pas une interruption, mais une exception.

la division par zéro n'est pas une interruption, mais une exception.

La "page fault" n'est pas une interruption,mais une exception.

Ces deux mécanismes (interruptions et exceptions) se subdivisent
d'ailleurs :

- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".

- Les exceptions se subdivisent en "faults", "Traps" et "aborts".
Vincent Burel
Le #17886051
"Papouille" news:49230d2d$0$13865$
Vincent Burel a écrit :
>
> Une interruption, comme sont nom l'indique est qqc qui va venir


interrompre
> le cours normal des choses.
> La prévisibilité (plus ou moins relative d'ailleurs) d'une interruption


ne
> change pas la nature du phénomène : l'interruption du cours du programme
> principale. Après il faut entendre ce qu'on entend par "prévisible" ,


quand
> on attend une interruption d'un controler disk en réponse à une requète,


on
> sait qu'il va y avoir une interruption, mais on ne sait pas quand.


C'est
> pareil pour la division par zero, y'a des calcul où l'on ne sait pas


dire
> facilement, de manière déterministe si quand un zéro va apparaitre sur


un
> diviseur.
>
> VB

Oui, mais non, nous ne sommes pas sur la même longueur d'onde...



oui, j'ai du mal à vous suivre.

Ce qui est prévisible n'est pas une interruption, mais une exception.



une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à
mettre en place ce mécanisme.

- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".



L'exception provoque généralement une interruption...

Bref, je ne comprend plus votre question.
peut etre qqn d'autre...
VB
Papouille
Le #17887431
Vincent Burel a écrit :

une exception n'est pas forcément prévisible, sinon y'aurait aucun intérêt à
mettre en place ce mécanisme.



En fait, si vous chargez un registre du microprocessuer avec la valeur 0
puis utilisez une instruction en langage machine faisant la division
d'un nombre avec le contenu de ce registre, vous provoquez une
exception. Si vous exécutez à nouveau le même programme dans les mêmes
conditions (mêmes paramètres d'entrée du programme) vous provoquerez à
nouveau l'exception.

Cette exception est traitée par une routine d'interruption, puis le
programme reprend là où l'exception a été générée. C'est-à-dire qu'il
re-exécute la même instruction. Donc il y a une ressemblance avec les
interruptions "ordinaires" dans le sens où effectivement intervient une
routine d'interruption, mais une différence avec une interruption
ordinaire dans le sens où :
1/ En re-exécutant deux fois le même programme avec les mêmes paramètres
d'entrée, l'exception sera à nouveau provoquée, à la différence d'une
"interruption" qui peut être provoquée à tout moment entre n'importe
quelle instruction, quels que soeint les paramètres d'entrée du programme
2/ Une exception, après traitement, reprend l'exécution du programme en
re-exécutant l'instruction l'ayant provoquée. Une interruption, elle,
provoque le retour du programme sur l'instruction *suivante* de celle
ayant été interrompue.


- Les interruptions se subdivisent en "Interruptions Hardware" et
"interruptions software".



L'exception provoque généralement une interruption...

Bref, je ne comprend plus votre question.
peut etre qqn d'autre...
VB



Ce n'est pas simple : pour moi, les interruptions software sont
prévisibles. Comme les exceptions... alors pourquoi les appeler
"interruptions" ? j'ai deux possibilités, mqis qui ne me convainquent pas :
1/ retour sur le programme interrompu : l'interruption software fait
reprendre l'exécution du programme sur l'instruction suivant celle ayant
été interrompue. Comme les interruptions software. Mais je ne retrouve
pas ici la définition de l'interruption au sens "d'évènement imprévisible".
2/ Les interruptions software, si elles sont contenues dans un thread du
kernel, peuvent imposer l'interruption d'un user-thread (préemption du
user-thread par le kernel) dans la mesure où elles s'exécutent à une
priorité (IRQL) plus élevée que celle du user-thread en cours
d'exécution. Le user thread s'est interrompu de manière "imprévisble".
On retrouve l'imprévisibilité de l'interruption du point de vue du
user-thread. Par contre ce n'était pas imprévisible du point de vue du
kernel-thread.... Mais cela me laisse perplexe... je ne suis pas
convaincu...
Publicité
Poster une réponse
Anonyme