Interruptions software

Papouille wrote:

Les interruptions sont imprévisibles.
En quoi les interruptions *software* le sont ?

Il n'y a pas de notion d'"imprevisible" dans les interruptions software
Dans les docs Intel, il est dit que les interruptions hardware dependent
des signaux hardware pouvant arriver "au hasard" et les interruptions
software de l'exécution de INT n, INTO, ..

"Papouille" <Papouille@papouille.net> wrote in message
news:49233ac1$0$970$426a74cc@news.free.fr...

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

Pas tout à fait, je comprend que vous disiez que l'exception est qqc que
l'on peut reproduire à tout coup, mais il en est de même pour
l'interruption, à chaque fois que vous appuyez sur une touche de votre
clavier vous provoquez une interruption.
Quand je dis que l'exception n'est pas plus prévisible que l'interruption,
je ne m'exprime pas contre le fait qu'on puisse les provoquer, j'exprimer le
fait qu'il y a une notion d'imprivisibilité (au moins temporelle) dans
l'apparition d'une interruption ou d'une exception. Et tout ceux qui font un
peu de calcul numérique vous diront qu'ils ont souvent été surpris par
l'apparition de telle ou telle exception (Division par ZERO, NAN etc...) par
ce qu'une exception n'apparait pas forcément de manière aussi déterministe
que vous le voulez, par exemple l'apparition d'un NAN ou d'un ZERO dans une
cellule mémoire peut etre l'oeuvre d'un process qui fait des débordements
mémoire, ca peut être aussi la conséquence d'une RAM qui disfonctionne, donc
d'un problème hardware...

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.

Oui, mais attention, une interruption arréte le déroulement du programme,
entre 2 instructions processeur (toujours). A contrario, l'exception se
produit pendant l'exécution d'une instruction processeur, c'est pourquoi
cette instruction est ré-exécutée si l'on revient à l'endroit qui a provoqué
l'exception. C'est ce en quoi on peut différencier les deux.

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...

C'est parce que vous n'admettez pas qu'une interruption (logicielle ou
matérielle) ou qu'une exception, puisse etre imprévisible (du point de vu du
logiciel).

VB

Domi a écrit :

Papouille wrote:

Les interruptions sont imprévisibles.
En quoi les interruptions *software* le sont ?

Il n'y a pas de notion d'"imprevisible" dans les interruptions software
Dans les docs Intel, il est dit que les interruptions hardware dependent
des signaux hardware pouvant arriver "au hasard" et les interruptions
software de l'exécution de INT n, INTO, ..

Les docs intels définissent en fait une interruption comme étant un
"asynchronous event", et une exception comme un "synchronous event".

Quel est le sens de "synchronous" et "asynchronous" ?

Bien cordialement

Papouille

Vincent Burel a écrit :

Pas tout à fait, je comprend que vous disiez que l'exception est qqc que
l'on peut reproduire à tout coup, mais il en est de même pour
l'interruption, à chaque fois que vous appuyez sur une touche de votre
clavier vous provoquez une interruption.

Oui mais la frappe sur le clavier est un évènement aléatoire du point de
vue du système. Pas l'exception.

Quand je dis que l'exception n'est pas plus prévisible que l'interruption,
je ne m'exprime pas contre le fait qu'on puisse les provoquer, j'exprimer le
fait qu'il y a une notion d'imprivisibilité (au moins temporelle) dans
l'apparition d'une interruption ou d'une exception. Et tout ceux qui font un
peu de calcul numérique vous diront qu'ils ont souvent été surpris par
l'apparition de telle ou telle exception (Division par ZERO, NAN etc...) par
ce qu'une exception n'apparait pas forcément de manière aussi déterministe
que vous le voulez, par exemple l'apparition d'un NAN ou d'un ZERO dans une
cellule mémoire peut etre l'oeuvre d'un process qui fait des débordements
mémoire, ca peut être aussi la conséquence d'une RAM qui disfonctionne, donc
d'un problème hardware...

Oui, vous avez raison, mais on ne parle pas de la même chose : si toutes
les même conditions sont toutes à nouveau réunies, c'est-à-dire si la
mémoire est rigoureusement dans le même état, l'exception est prévisible
: elle se reproduira à nouveau sur la même instruction.

C'est complètement déterministe. Une cellule mémoire à zéro dans un cas
doit à nouveau être à zéro pour que l'exception puisse à nouveau se
reproduire. C'est pour cela que j'ai précisé que toutes les conditions
devaient être les mêmes pour que l'exception se reproduise.

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.

Oui, mais attention, une interruption arréte le déroulement du programme,
entre 2 instructions processeur (toujours). A contrario, l'exception se
produit pendant l'exécution d'une instruction processeur, c'est pourquoi
cette instruction est ré-exécutée si l'on revient à l'endroit qui a provoqué
l'exception. C'est ce en quoi on peut différencier les deux.

Oui oui c'est bien cela.

C'est parce que vous n'admettez pas qu'une interruption (logicielle ou
matérielle) ou qu'une exception, puisse etre imprévisible (du point de vu du
logiciel).

J'admets qu'une interruption hardware est imprévisible, car son
occurence dépend d'évènements extérieurs aléatoires.

Ce que je n'admets pas, c'est qu'une interruption software soit dite
"imprévisible", de la même façon qu'une exception ne l'est pas non plus
: elle est déterministe (toutes choses étant égales dans le système
entre la première fois que l'exception a été détectée et la seconde fois)

VB

Papouille a écrit :

Domi a écrit :

Papouille wrote:

Les interruptions sont imprévisibles.
En quoi les interruptions *software* le sont ?

Il n'y a pas de notion d'"imprevisible" dans les interruptions software
Dans les docs Intel, il est dit que les interruptions hardware
dependent des signaux hardware pouvant arriver "au hasard" et les
interruptions software de l'exécution de INT n, INTO, ..

Les docs intels définissent en fait une interruption comme étant un
"asynchronous event", et une exception comme un "synchronous event".

Quel est le sens de "synchronous" et "asynchronous" ?

Bien cordialement

Papouille

J'ai trouvé ça dans un livre sur Windows :

"The kernel distinguishes between interrupts and exceptions in the
following way. An interrupt is an asynchronous event (one that can occur
at any time) that is unrelated to what the processor
is executing. Interrupts are generated primarily by I/O devices,
processor clocks, or
timers, and they can be enabled (turned on) or disabled (turned off). An
exception, in contrast,
is a synchronous condition that results from the execution of a
particular instruction"

Vincent Burel a écrit :

C'est parce que vous n'admettez pas qu'une interruption (logicielle ou
matérielle) ou qu'une exception, puisse etre imprévisible (du point de vu du
logiciel).

VB

Voir mon post en réponse à Domi :
"The kernel distinguishes between interrupts and exceptions in the
following way. An interrupt
is an asynchronous event (one that can occur at any time) that is
unrelated to what the processor
is executing. Interrupts are generated primarily by I/O devices,
processor clocks, or
timers, and they can be enabled (turned on) or disabled (turned off). An
exception, in contrast,
is a synchronous condition that results from the execution of a
particular instruction".

Ma question est : pourquoi les interruptions software sont classées dans
la catégorie "interrupt" ?

"Papouille" <Papouille@papouille.net> wrote in message
news:49246c9c$0$8495$426a74cc@news.free.fr...

Vincent Burel a écrit :
> C'est parce que vous n'admettez pas qu'une interruption (logicielle ou
> matérielle) ou qu'une exception, puisse etre imprévisible (du point de

vu du

> logiciel).
>
> VB

Voir mon post en réponse à Domi :
"The kernel distinguishes between interrupts and exceptions in the
following way. An interrupt
is an asynchronous event (one that can occur at any time) that is
unrelated to what the processor
is executing. Interrupts are generated primarily by I/O devices,
processor clocks, or
timers, and they can be enabled (turned on) or disabled (turned off). An
exception, in contrast,
is a synchronous condition that results from the execution of a
particular instruction".

Ma question est : pourquoi les interruptions software sont classées dans
la catégorie "interrupt" ?

Simplement , parce qu'elle provoque l'interruption du cours du programme.

Bonjour,

Papouille a écrit :

Vincent Burel a écrit :

C'est parce que vous n'admettez pas qu'une interruption (logicielle ou
matérielle) ou qu'une exception, puisse etre imprévisible (du point de
vu du
logiciel).

VB

Voir mon post en réponse à Domi :
"The kernel distinguishes between interrupts and exceptions in the
following way. An interrupt
is an asynchronous event (one that can occur at any time) that is
unrelated to what the processor
is executing. Interrupts are generated primarily by I/O devices,
processor clocks, or
timers, and they can be enabled (turned on) or disabled (turned off). An
exception, in contrast,
is a synchronous condition that results from the execution of a
particular instruction".

Ma question est : pourquoi les interruptions software sont classées dans
la catégorie "interrupt" ?

Je te retourne la question, tu les classerais ou ?

Michel__D a écrit :

Ma question est : pourquoi les interruptions software sont classées
dans la catégorie "interrupt" ?

Je te retourne la question, tu les classerais ou ?

Bonjour,

Je les classerais dans les interruptions, mais pas en raison de la
classification donnée dans ce livre (asynchronous event), mais pour le
mécanisme de retour de l'interruption (continue sur l'instruction
suivant celle ayant été interrompue).

Bien cordialement

Papouille

Papouille a écrit :

Michel__D a écrit :

Ma question est : pourquoi les interruptions software sont classées
dans la catégorie "interrupt" ?

Je te retourne la question, tu les classerais ou ?

Bonjour,

Je les classerais dans les interruptions, mais pas en raison de la
classification donnée dans ce livre (asynchronous event), mais pour le
mécanisme de retour de l'interruption (continue sur l'instruction
suivant celle ayant été interrompue).

Et bien la boucle est bouclée, on dirait.

PS:Il ne faut pas forcément croire tout ce que les livres racontent.