La gestion des interruptions sous LabVIEW - niveaux de priorité - Scheduler

[Desruelle_luc]

http://forums.ni.com/t5/Discussions-au-sujet-de-NI/Les-interruptions/m-p/2446998/highlight/true#M766...

j'ai bcp aimé l'article de Florina Abry - Naity

Re : Les interrupti​ons.

le ‎03-06-201310:31 AM

par

Florian Abry
Application Engineer
NI Germany

Bonjour,

Je me permets de rajouter un mot ou deux sur ce qu'a dit Ouadji.

Lors de la programmation micro contrôleur, on programme directement en langage machine. Il est donc nécessaire de gérer les interruptions de manière manuelle pour autoriser le contrôleur d’exécuter plusieurs tâches de manière pseudo-parallèle.

L’introduction des systèmes d’exploitation à changer la donne. Ces systèmes (type Windows) proposent une surcouche logicielle qui s’occupe, entre-autre, de gérer les exploitations. Cette action est réalisée via un de leur composant nommé « Scheduler » (ou ordonnanceur en français, voir wiki).

Ce Scheduler s’occupe, via un algorithme bien définit, de gérer les interruptions des différentes tâches concurrentes tournant sur un même système (on parle de Process (processus) pour els différentes applications tournant en parallèle (par Exemple, Windows en parallèle avec Foobar pour la musique, Opera pour le web et un client Thunderbird pour les mails. Le Scheduler doit faire en sorte que vous puissiez surfer tout en écoutant de la musique) et de Threads pour les tâches parallèle au sein d’un même processus (exemple type : Windows Media Player à un visualizer qui tourne en parallèle avec le lecteur de musique)). Pour que tout ce beau monde tourne d’une manière donnant l’illusion d’être parallèle, le Scheduler doit sans cesse jongler avec ces threads en les interrompant les-uns les autres.

Les premiers scheduler (celui de Windows 3 par exemple, si je ne dis pas de bêtises) se contentaient de laisser un temps défini à chaque thread, sans notion de priorité. C’est ce que l’on appelle le « Round-Robin Scheduling » (wiki). Plus tard, un autre type de scheduling à fait son apparition, plus proche des possibilités données par els interruptions de Microcontrôleur : Le « Preemptive Scheduling » (wiki). Cet algorithme d’ordonancement permet d’allouer des niveaux de priorité aux tâches pour qu’une tâche de priorité plus importante interrompe toutes tâches de prioroité moindre lorsque celle-ci doit être exécutée.

Oui mais LabVIEW dans tout ca ?

Il y a d’autres types d’ordonnancement, mais ces deux là représentent de mon point de vue la base nécessaire à comprendre les systèmes d’interruptions des systèmes d’exploitation sur lesquels LabVIEW tourne.

Je me focaliserais sur deux d’entre-eux :

Windows 7 :

Je ne suis pas extrêmement familier avec le Scheduler de Windows 7. De ce que j’en ai compris, il fonctionne comme un mix de Scheduling Round-Robin et de Preemptive Scheduling. Les différentes tâches ont des niveaux de priorité. Les tâches de haute priorité interrompent les tâches de basses priorités. Cependant, il me semble que le scheduler peut aussi interrompre les tâches de haute priorité si celles-ci prennent trop de temps d’exécution pour garantir une exécution minimale pour els tâches de basse priorité. La plupart des niveaux de priorité ne sont utilisables que par le Système d’exploitation.

Cela signifie qu’un programme labVIEW peut avoir différent niveaux de priorité, mais jamais les plus haut et qu’une tâche exécutée sous labVIEW peut être à tout moment interrompue par Windows.

Pour changer le niveau de priorité, il y a 3 méthodes :

* Définir le processus LabVIEW.exe comme processus de haute priorité dans le gestionnaire des tâches de Windows.

* Utiliser une « Timed Loop ». Ce faisant, vous réduirez l’algorithme dans la boucle à un thread et ce thread sera d’une plus haute priorité que les autres threads du processus en cours. Attention donc, la réduction de l’algorithme à un thread peut entrainer des Race Conditions assez dramatiques et cette priorité n’est que relative au programme. Les autres programmes et processus (dont ceux de windows) peuvent interrompre ce thread à tout moment.

* Dans les propriétés ‘exécution d’un VI, il est possible de configurer la priorité de ce VI. Encore une fois, cette priorité est relative aux autres Vis.

Conclusion : il n’est pas possible de créer de « vrais » mécanismes d’interruption pour un programme LanVIEW sous Windows.

LabVIEW Real-Time OS :

Le Scheduler de LabVIEW Real-Time OS fonctionne de manière quasi purement préemptive. Toute tâche de priorité supérieure interrompra une tâche de priorité inférieure et toute tâche de priorité inférieure ne pourra être exécutée qu’une fois toutes les tâches de priorité supérieures finies. En cas de tâches de priorité équivalente, c’est la règle de « Round Robin » qui s’applique. LabVIEW Real-Time autorise LabVIEW à utiliser tous les niveaux de priorité.

Les moyens de définir cette priorité est équivalente aux deux derniers points soulevés dans le paragraphe sur Windows, avec la particularité que cette fois, la priorité d’une tâche est absolue.

Conclusion : Même si les interruptions processeur sont prise en charge par la surcouche logicielle du système d’exploitation, il est possible d’avoir un contrôle quasi-total sur les interruptions (avec la seule limite que LabVIEW n’autorise pas à donner une priorité telle à un processus que celui-ci pourrait interrompre le scheduler).

J’espère que cette petite explication sera utile à tous. N’hésitez pas à donner des Kudos si c’est le cas.

Cordialement

[Desruelle_luc]

Bonjour,

Je me permets de rajouter un mot ou deux sur ce qu'a dit Ouadji.

Lors de la programmation micro contrôleur, on programme directement en langage machine. Il est donc nécessaire de gérer les interruptions de manière manuelle pour autoriser le contrôleur d’exécuter plusieurs tâches de manière pseudo-parallèle.

L’introduction des systèmes d’exploitation à changer la donne. Ces systèmes (type Windows) proposent une surcouche logicielle qui s’occupe, entre-autre, de gérer les exploitations. Cette action est réalisée via un de leur composant nommé « Scheduler » (ou ordonnanceur en français, voir wiki).

Ce Scheduler s’occupe, via un algorithme bien définit, de gérer les interruptions des différentes tâches concurrentes tournant sur un même système (on parle de Process (processus) pour els différentes applications tournant en parallèle (par Exemple, Windows en parallèle avec Foobar pour la musique, Opera pour le web et un client Thunderbird pour les mails. Le Scheduler doit faire en sorte que vous puissiez surfer tout en écoutant de la musique) et de Threads pour les tâches parallèle au sein d’un même processus (exemple type : Windows Media Player à un visualizer qui tourne en parallèle avec le lecteur de musique)). Pour que tout ce beau monde tourne d’une manière donnant l’illusion d’être parallèle, le Scheduler doit sans cesse jongler avec ces threads en les interrompant les-uns les autres.

Les premiers scheduler (celui de Windows 3 par exemple, si je ne dis pas de bêtises) se contentaient de laisser un temps défini à chaque thread, sans notion de priorité. C’est ce que l’on appelle le « Round-Robin Scheduling » (wiki). Plus tard, un autre type de scheduling à fait son apparition, plus proche des possibilités données par els interruptions de Microcontrôleur : Le « Preemptive Scheduling » (wiki). Cet algorithme d’ordonancement permet d’allouer des niveaux de priorité aux tâches pour qu’une tâche de priorité plus importante interrompe toutes tâches de prioroité moindre lorsque celle-ci doit être exécutée.

Oui mais LabVIEW dans tout ca ?

Il y a d’autres types d’ordonnancement, mais ces deux là représentent de mon point de vue la base nécessaire à comprendre les systèmes d’interruptions des systèmes d’exploitation sur lesquels LabVIEW tourne.

Je me focaliserais sur deux d’entre-eux :

Windows 7 :

Je ne suis pas extrêmement familier avec le Scheduler de Windows 7. De ce que j’en ai compris, il fonctionne comme un mix de Scheduling Round-Robin et de Preemptive Scheduling. Les différentes tâches ont des niveaux de priorité. Les tâches de haute priorité interrompent les tâches de basses priorités. Cependant, il me semble que le scheduler peut aussi interrompre les tâches de haute priorité si celles-ci prennent trop de temps d’exécution pour garantir une exécution minimale pour els tâches de basse priorité. La plupart des niveaux de priorité ne sont utilisables que par le Système d’exploitation.

Cela signifie qu’un programme labVIEW peut avoir différent niveaux de priorité, mais jamais les plus haut et qu’une tâche exécutée sous labVIEW peut être à tout moment interrompue par Windows.

Pour changer le niveau de priorité, il y a 3 méthodes :

* Définir le processus LabVIEW.exe comme processus de haute priorité dans le gestionnaire des tâches de Windows.

* Utiliser une « Timed Loop ». Ce faisant, vous réduirez l’algorithme dans la boucle à un thread et ce thread sera d’une plus haute priorité que les autres threads du processus en cours. Attention donc, la réduction de l’algorithme à un thread peut entrainer des Race Conditions assez dramatiques et cette priorité n’est que relative au programme. Les autres programmes et processus (dont ceux de windows) peuvent interrompre ce thread à tout moment.

* Dans les propriétés ‘exécution d’un VI, il est possible de configurer la priorité de ce VI. Encore une fois, cette priorité est relative aux autres Vis.

Conclusion : il n’est pas possible de créer de « vrais » mécanismes d’interruption pour un programme LanVIEW sous Windows.

LabVIEW Real-Time OS :

Le Scheduler de LabVIEW Real-Time OS fonctionne de manière quasi purement préemptive. Toute tâche de priorité supérieure interrompra une tâche de priorité inférieure et toute tâche de priorité inférieure ne pourra être exécutée qu’une fois toutes les tâches de priorité supérieures finies. En cas de tâches de priorité équivalente, c’est la règle de « Round Robin » qui s’applique. LabVIEW Real-Time autorise LabVIEW à utiliser tous les niveaux de priorité.

Les moyens de définir cette priorité est équivalente aux deux derniers points soulevés dans le paragraphe sur Windows, avec la particularité que cette fois, la priorité d’une tâche est absolue.

Conclusion : Même si les interruptions processeur sont prise en charge par la surcouche logicielle du système d’exploitation, il est possible d’avoir un contrôle quasi-total sur les interruptions (avec la seule limite que LabVIEW n’autorise pas à donner une priorité telle à un processus que celui-ci pourrait interrompre le scheduler).

J’espère que cette petite explication sera utile à tous. N’hésitez pas à donner des Kudos si c’est le cas.

Cordialement