Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Environnement Microsoft prehemption

prehemption

27 réponses
Avatar
Ambassadeur Kosh
on a 2 valeurs à aller pecher sur des ports differents.
le probleme est que entre ces deux "acquisitions", le thread peut se faire
prehempter.
c'est normal, l'ordonanceur fait son boulot.

la question est, comment faire en sorte de ne pas être prehempté. paske
sinon, ça cree un décalage énorme dans le temps (100ms, ça n'est pas rien)
et du coup, le couple de valeurs n'a pas de sens.

bon, c'est le même probleme que pour le port série, donc ça doit se résoudre
d'une façon trés voisine. mais comment faire en sorte d'avoir les bonnes
propriétés : cad pas de perte de donnée, pas d'attente active, pas de
prehemption au moment ou je pique mes deux valeurs pour avoir la
"simultaneité". en clair, comment écrire le Read.

j'ai un début d'idée, mais je voudrais bien un exposé technique des habitués
du forum avant de faire pencher la balance. ( Arnaud, Quentin ou Amcd pour
ne citer qu'eux :) )

d'avance merci
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Ambassadeur Kosh
> Parce que :
1) Laisser un thread avec ce niveau de priorité pendant longtemps (ie
plus de quelques ms) a la facheuse tendance à déstabiliser Windows
(certains de ces services indsipensables n'ayant plus de temps
processeur pour travailler).



c'est clair, mais y'aura pas de dérive. le thread doit roupiller tel la
cendrillon de base pendant 10 secondes et se reveiller pour bosser
pendant 2 milliardiemes de secondes et aller se recoucher. et le
boulot a interet à être bien fait sinon....

2) On peut toujours être préhempté par une interruption.



c'est bien ce qu'il me semblait. mais, peut on postuler que le temps
passé en mode noyau est toujours infiniment plus court que le quantum
de temps alloué à un thread ? si oui, ben c'est pas si mal que
ça finalement.

Il me semble que la solution serait d'écrire un driver pour le port
série qui, lorsqu'il recoit l'interruption de données disponible,
lance immédiatement l'acquisition sur la carte dédiée (éventuellement
en levant une autre INT gérée par le driver de la carte
d'acquisition). Par contre, je ne connais pas assez le DDK pour donner
des conseils de mise en oeuvre de ce genre de choses.



moi non plus !!! au secouuuuurrrs aaaaarggg.
l'Universalis, c'est le journal de Mickey à côté du DDK.
Avatar
Vincent Burel
"Ambassadeur Kosh" wrote in message
news:bmmcsf$fpj$
> 2) On peut toujours être préhempté par une interruption.

c'est bien ce qu'il me semblait. mais, peut on postuler que le temps
passé en mode noyau est toujours infiniment plus court que le quantum
de temps alloué à un thread ? si oui, ben c'est pas si mal que
ça finalement.



ben non, on ne peut pas postuler ca du tout , sinon y'aurait plein de truc
temps-réel qui marcherai du feu de dieu sous windows. Le système peut
générer des retard de l'ordre de 100ms de 500ms voir de plusieurs seconde,
même dans un thread TIME_CRITICAL et même si le processing est fait dans la
callback (virtuelle) d'un drivers.

Vincent Burel
Avatar
Arnaud Debaene
Vincent Burel wrote:
"Arnaud Debaene" wrote in message
news:
"Vincent Burel" wrote in message


news:<bmjstd$uqj$...
"Ambassadeur Kosh" wrote in message
news:bmjr93$moa$
et en mettant ca dans un thread TIME_CRITICAL...


pas bête.
mais n'est ce pas qu'un paliatif ?



Ben non. Pourquoi !?



Parce que :
1) Laisser un thread avec ce niveau de priorité pendant longtemps
(ie plus de quelques ms) a la facheuse tendance à déstabiliser
Windows (certains de ces services indsipensables n'ayant plus de
temps
processeur pour travailler).



Wow, faut pas diaboliser le TIME_CRITICAL ! au pire vous aurez une
comportment en saccade si le Thread TIME_CRITICAL fait des traitement
long de 30ms par exemple toutes les 50 ms. Mais bon faut savoir
qu'est ce que vous voulez prioriser dans votre application. Mais une
instabilité ! non. sauf si le thread ne "respire" pas. c'est sur, si
vous lancez un Thread TIME CRITICAL pour copier 50 Go de données,
alors là votre Windows pourra paraitre un peu bloqué jusqu'à la fin
de l'opération ou presque... Mais dans l'exemple qui nous concerne,
le thread en question ne fera pratiquement rien puisqu'il passera son
temps à attendre un event du port série via la fonction read... donc
vous le sentirez même pas qu'il est TIME_CRITICAL..



Extrait de "Inside Windows 2000" :
"Be aware that many important Windows 2000 kernel-mode system threads run in
the realtime priority range, so if your process spends excessive time
running in this range, it might be blocking critical system functions in the
memory manager, cache manager, local and network file systems, and even
other device drivers. It won't block hardware interrupts because they have a
higher priority than any thread, but it might block system threads from runn
ing".

2) On peut toujours être préhempté par une interruption.

Il me semble qaue la solution serait d'écrire un driver pour le port
série qui, lorsqu'il recoit l'interruption de données disponible,
lance immédiatement l'acquisition sur la carte dédiée (éventuellement
en levant une autre INT gérée par le driver de la carte
d'acquisition). Par contre, je ne connais pas assez le DDK pour
donner des conseils de mise en oeuvre de ce genre de choses.



qu'est ce que ca change , que vous écriviez le driver ou pas , c'est
pas vous qui allez dire à Windows que le port série doit être plus
prioritaire que le controler IDE et la carte réseaux.


Je n'en suis pas certain justement. AMcD ou un autre habitué du DDK sait
peut être : est-ce qu'il n'est pas possible de spécifier une INT Level au
moment de l'installation d'un driver? De toute façon, vu le type
d'application, il doit être possible de contrôler au moins partiellement
l'activité des périphériques présents.

Et puis les
drivers communiquent à l'application par event, et c'est windows qui
s'occupe des event.


Là n'est pas le problème : si le driver est capable de faire l'acquisition
dans les délais requis et de mettre les résultats dans un buffer, le temps
de réaction de l'application qui fait le traitement derrière n'est plus
fondamental (du moment qu'il est inférieur à l'intervalle entre deux
mesures).

Même dans l'audio, les faiseurs de driver
n'arrivent pas à garantir l'arrivée des event à temps. parce que le
mécanisme Windows ne le permet tout simplement pas.


Si tu as des références sur le sujet, ca pourrait intéresser Ambassadeur
Kosh (et d'autres).

Arnaud
Avatar
Vincent Burel
"Arnaud Debaene" wrote in message
news:3f8edd52$0$13299$
Extrait de "Inside Windows 2000" :
"Be aware that many important Windows 2000 kernel-mode system threads run


in
the realtime priority range, so if your process spends excessive time
running in this range, it might be blocking critical system functions in


the
memory manager, cache manager, local and network file systems, and even
other device drivers. It won't block hardware interrupts because they have


a
higher priority than any thread, but it might block system threads from


runn
ing".



y'a 32 niveaux de priorité thread sous windows et je propose d'utiliser la
TIME_CRITICAL d'appli de classe normal, ce qui fait un priority n° 15 . le
système est un process qui n'est pas de class normal, mais de class
TIME_CRITICAL. D'ailleurs si votre appli normal fait un thread TIME_CRITICAL
plein, le control supervisor continue d'être accessible.

> Et puis les
> drivers communiquent à l'application par event, et c'est windows qui
> s'occupe des event.
Là n'est pas le problème : si le driver est capable de faire l'acquisition
dans les délais requis



sa dépend de la priorité du hardware qu'il controle.

et de mettre les résultats dans un buffer,



et un event pour dire que c'est fait.

le temps
de réaction de l'application qui fait le traitement derrière n'est plus
fondamental (du moment qu'il est inférieur à l'intervalle entre deux
mesures).



Très intelligent ca. c'est du style : " la température n'est pas un problème
fondamental (du moment qu'elle ne descent pas en dessous de 25 degrées)"
:-))

> > Même dans l'audio, les faiseurs de driver
> n'arrivent pas à garantir l'arrivée des event à temps. parce que le
> mécanisme Windows ne le permet tout simplement pas.
Si tu as des références sur le sujet, ca pourrait intéresser Ambassadeur
Kosh (et d'autres).



Si vous ne me croyez pas, faites donc perdre du temps à Ambassadeur Kosh,
qu'il fasse des drivers et qu'ils se rende compte par lui - même...

VB
Avatar
Ambassadeur Kosh
> >le temps
> de réaction de l'application qui fait le traitement derrière n'est plus
> fondamental (du moment qu'il est inférieur à l'intervalle entre deux
> mesures).

Très intelligent ca. c'est du style : " la température n'est pas un


problème
fondamental (du moment qu'elle ne descent pas en dessous de 25 degrées)"
:-))



non, sur le coup la, il a bien vu.
par chance, je n'ai pas de traitement réactif à faire.
une fois l'objet mesuré, il continue de vivre sa vie.
le resultat de l'optimisation est utile à un controleur qui fera du boulot
bien plus "loin" et ou le systeme fera attendre l'objet jusqu'à ce que le
résultat arrive.

mais il y a des applications ou il y a du traitement reactif à faire aussi.

genre la gestion d'un trieur.
les objets passent devant des cellules, et quand l'objet passe devant la
bonne cellule, un taquet le pousse laterallement en dehors du tapi vers
une caisse. la faut réagir vite parceque le tapi, il fait pas du 2 metres
à l'heure... l'appli actuelle qui fait ça souffre de ce probleme. (je vous
dit pas la gueule du client quand l'objet arrive dans le mur, et qu'il faut
s'expliquer et justifier le montant de notre prestation)

mais je pense que dans ce cas la, c'est le driver qui doit "calculer" le
resultat de la fonction "est-ce que j'active le pousseur".
Avatar
Vincent Burel
"Ambassadeur Kosh" wrote in message
news:bmo5e7$otf$
> >le temps
> > de réaction de l'application qui fait le traitement derrière n'est


plus
> > fondamental (du moment qu'il est inférieur à l'intervalle entre deux
> > mesures).
>
> Très intelligent ca. c'est du style : " la température n'est pas un
problème
> fondamental (du moment qu'elle ne descent pas en dessous de 25 degrées)"
> :-))



non, sur le coup la, il a bien vu.
par chance, je n'ai pas de traitement réactif à faire.
une fois l'objet mesuré, il continue de vivre sa vie.
le resultat de l'optimisation est utile à un controleur qui fera du boulot
bien plus "loin" et ou le systeme fera attendre l'objet jusqu'à ce que le
résultat arrive.



Ha, vous vouliez dire que le driver s'occuperait de l'acquisition et de la
mesure.
cela ne changera pas grand chose, cela diminuera l'erreur de mesure due au
mécanisme d'Event de communication à l'application, mais y'aura toujours un
proplème de priorité d'interruption qui fera que vous aurez quand même des
fluctuations importantes.

VB
Avatar
AMcD
Arnaud Debaene wrote:

Je n'en suis pas certain justement. AMcD ou un autre habitué du DDK
sait peut être : est-ce qu'il n'est pas possible de spécifier une INT
Level au moment de l'installation d'un driver? De toute façon, vu le
type d'application, il doit être possible de contrôler au moins
partiellement l'activité des périphériques présents.



Cela fait malheureusement bien longtemps que je ne mets plus le nez dedans
:o(. Je pense toutefois que notre ami devrait lire le plus vite possible le
chapitre 4 (Synchronization) du bouquin de Walter Oney. Je cite quelques
passages :

"All we need to understand as driver writers is that our code executes in
the context of one thread or another (and the thread context can change from
one invocation of our code to another) and that the exigencies of
multitasking can yank control away from us at practically any moment.
Furthermore, true simultaneous execution of multiple threads is possible on
a multiprocessor machine. In general, we need to assume two worst-case
scenarios:

- The operating system can preempt any subroutine at any moment for an
arbitrarily long period of time, so we cannot be sure of completing critical
tasks without interference or delay.

- Even if we take steps to prevent preemption, code executing simultaneously
on another CPU in the same computer can interfere with our code-it's even
possible that the same set of instructions belonging to one of our programs
could be executing in parallel in the context of two different threads."

[...]

"Thread priority is a very different concept from IRQL. Thread priority
controls the actions of the scheduler in deciding when to preempt running
threads and what thread to start running next. The only "priority" that
means anything at IRQLs above APC_LEVEL is IRQL itself, and it controls
which programs can execute rather than the thread context within which they
execute."

En fait, les parties "Servicing an interrupt" ou "handling interrupts" du
chapitre 7 lui seront aussi utiles. Finalement, faut l'avoir lu en entier ce
livre :o).

--
AMcD

http://arnold.mcdonald.free.fr/
1 2 3