Appel périodique de fonction

Je trouve la programmation interruptible pire car je trouve la désactivation des signaux plus compliquée et moins performante que l'emploi de sections critiques (j'admets que je suis sans doute biaisé de ce côté-là).

Et je peux dire la même chose pour unix/linux: Le noyau a longtemps été incapable de gérer le multithreading sans utiliser des hacks bizarres comme créer plusieurs processus et les repartager, voire pire, tout gérer côté user...

Windows NT a toujours eu un noyau capable de gérer thread par thread et de faire la différence entre un thread et un processus...

Citation:

---

Envoyé par Médinoc

Je trouve la programmation interruptible pire car je trouve la désactivation des signaux plus compliquée et moins performante que l'emploi de sections critiques (j'admets que je suis sans doute biaisé de ce côté-là).

Et je peux dire la même chose pour unix/linux: Le noyau a longtemps été incapable de gérer le multithreading sans utiliser des hacks bizarres comme créer plusieurs processus et les repartager, voire pire, tout gérer côté user...

Windows NT a toujours eu un noyau capable de gérer thread par thread et de faire la différence entre un thread et un processus...

---

lol oui tu es biaisé.. ;)

Et il est parfaitement normal que unix/linux ne faisaient pas de multithreading et que c'était compliqué. IL N'Y EN A PAS BESOIN !!!!!!!!!!!

Par DEFINITON c'était multi-process multi-usagers (comme tous les OS dignes de ce nom d'ailleurs (mvs, vms, solaris, et autres)). Tu parles d'ailleurs de Windows NT.. Qui n'est pas si vieux.. Sous Win9x, rien de tout cela :P

Et les signaux sont la base de la communication inter-process, avec les COMMON (PSECT en assembleur). De même avec les sockets aysnchrones : le seul système sur lequel ils n'existaient pas au niveau profond était Win...

Dans n'importe quel cours système, on parle des signaux.

Je ne vois pas en quoi les gens se seraient fatiguer à faire des fonctions comme setitimer avec 3 types de timer si ça n'était pas utile....

Bref...

La réponse NATURELLE à la question "appel périodique" est "timer" , c'est tout : c'est la définition même... (minuterie en anglais)
(si on veut faire autre chose en // . Sinon sleep et ses variantes est bien sur mieux..)

Tu sembles oublier la lourdeur d'un changement de contexte entre processus par rapport un changement de thread...

De plus, si Win9x n'était pas multi-usager, il restait multi-process (mais sa séparation des processus était imparfaite).

Et les signaux, même s'ils sont "la base" comme tu dis, ont toujours l'inconvénient de pouvoir arriver n'importe quand tant qu'ils sont activés (programmation interruptible contre programmation événementielle). Même si ça peut être un avantage pour quelqu'un qui maîtrise, c'est plus facilement un inconvénient pour les débutants.


PS: En fait, si je veux appeler périodiquement une fonction sous Windows, j'utiliserais les fonctions CreateTimerQueue() et CreateTimerQueueTimer(), qui appellent périodiquement la fonction voulue dans un autre thread.

Citation:

---

Envoyé par Médinoc

Tu sembles oublier la lourdeur d'un changement de contexte entre processus par rapport un changement de thread...

---

D'une part, dans l'envoi de signaux, on ne change pas de contexte ...

Citation:

---

Envoyé par Médinoc

Et les signaux, même s'ils sont "la base" comme tu dis, ont toujours l'inconvénient de pouvoir arriver n'importe quand tant qu'ils sont activés (programmation interruptible contre programmation événementielle). Même si ça peut être un avantage pour quelqu'un qui maîtrise, c'est plus facilement un inconvénient pour les débutants.

---

Bah la notion de "out of memory", "erreur système", etc doit quand même être comprise un minimum, et ce sont bien des signaux.... Il me semble plus difficile d'assimiler la notion de "clone" avec un fork que d'assimiler la notion de programmation interrompue momentanément...

Car quand même, je ne vois pas ce qui fait la différence que tu mets entre "interruptible" et "événementielle", sauf que ce n'est pas au même niveau que ça se passe. Dans l'événementielle, c'est le programme utilisateur qui fait "while (1)", dans l'interruptible c'est le système, mais le principe est le même.. Un évènement déclenche une action...

Citation:

---

Envoyé par Médinoc

PS: En fait, si je veux appeler périodiquement une fonction sous Windows, j'utiliserais les fonctions CreateTimerQueue() et CreateTimerQueueTimer(), qui appellent périodiquement la fonction voulue dans un autre thread.

---

oui mais donc pourquoi ne conseilles-tu pas pour une utilisation unixoide l'équivalent SANS thread qui est setitimer ?????????

Un appel simple avec une fonction statique me semble beaucoup plus facile à comprendre conceptuellement qu'ajouter toute une théorie sur la communication inter-thread, la synchro, etc etc... surtout pour un débutant... mais même pour quelqu'un maitrisant plus...

Citation:

---

D'une part, dans l'envoi de signaux, on ne change pas de contexte ...

---

Là, j'ai vraiment des doutes. Même si on ne change pas de flot d'exécution, on traverse la barrière des processus, donc il y a de gros changement de contexte quand même...

Citation:

---

Car quand même, je ne vois pas ce qui fait la différence que tu mets entre "interruptible" et "événementielle", sauf que ce n'est pas au même niveau que ça se passe. Dans l'événementielle, c'est le programme utilisateur qui fait "while (1)", dans l'interruptible c'est le système, mais le principe est le même.. Un évènement déclenche une action...

---

À moins que ton while(1) soit vide, en programmation interruptible le signal peut arriver à tout moment dans la boucle (voire même avant). En événementiel, ça n'arrivera QUE dans la fonction d'attente, sans aucun risque de te déranger au milieu de quelque chose de critique.

Citation:

---

oui mais donc pourquoi ne conseilles-tu pas pour une utilisation unixoide l'équivalent SANS thread qui est setitimer ?????????

Un appel simple avec une fonction statique me semble beaucoup plus facile à comprendre conceptuellement qu'ajouter toute une théorie sur la communication inter-thread, la synchro, etc etc... surtout pour un débutant... mais même pour quelqu'un maitrisant plus...

---

En fait, je pense qu'à ce niveau-là il y a équivalence, sauf sur la méthode de synchro.
Si la fonction à appeler est complètement indépendante, aucun problème.

• Avec setitimer, dès que tu fais quelque chose de "critique", tu dois désactiver le signal et le réactiver ensuite.
• Avec le multithread, si tu fais quelque chose de critique, tu emploies un mutex ou équivalent.

En fait, j'avais un biais contre le coup de "désactiver les signaux", car je vois une granularité plus fine dans les mutexes.

Mais dans le cas présent, tu as raison, ça suffit. On dit donc setitimer() sous POSIX, CreateTimerQueueTimer() sous Windows, et on en reste là ?

Citation:

---

Envoyé par Médinoc

Là, j'ai vraiment des doutes. Même si on ne change pas de flot d'exécution, on traverse la barrière des processus, donc il y a de gros changement de contexte quand même...

---

ben non... Quand c'est à l'intérieur du même prog.. Et même quand c'est un autre.. Il ne le reçoit que si il est chargé. Donc il ne change pas de contexte non plus... (en fait le signal est un ensemble(flag+data) dans la partie réservée du système (là où sont les COMMON fortran et les Psect assembleurs, comme les sémaphores).

Mais même si c'était géré par l'OS "roulant", aucun des 2 progs ne changent de contexte.....

Citation:

---

Envoyé par Médinoc

En fait, je pense qu'à ce niveau-là il y a équivalence, sauf sur la méthode de synchro.
Si la fonction à appeler est complètement indépendante, aucun problème.

• Avec setitimer, dès que tu fais quelque chose de "critique", tu dois désactiver le signal et le réactiver ensuite.
• Avec le multithread, si tu fais quelque chose de critique, tu emploies un mutex ou équivalent.

En fait, j'avais un biais contre le coup de "désactiver les signaux", car je vois une granularité plus fine dans les mutexes.

---

oui ça c'est faux, puisque tu descends à la micro-seconde avec les timers...
Je ne connais pas les threads, mais j'imagine qu'on ne doit guère pouvoir descendre en-dessous...

Et comme tu le dis, il y a DE TOUTES façons une action à prendre pour protéger les parties critiques, ou pour synchroniser...

Et oui c'est sensiblement équivalent..Mais ça nécessite de comprendre et lire les concepts de thread, mutex, synchro, etc etc.....

Pourquoi faire simple quand on peut faire compliqué ? :aie:

Citation:

---

Envoyé par Médinoc

Mais dans le cas présent, tu as raison, ça suffit. On dit donc setitimer() sous POSIX, CreateTimerQueueTimer() sous Windows, et on en reste là ?

---

lol oui ;):D

NOTE:
1) d'ailleurs setitimer est égalment dispo sous Win avec cygwin... Je ne sais pas avec les autres outils....
2) si l'argument est qu'il n'y a pas de contexte (enfin du point de vue utilisateur), alors il faudrait interdire l'usage de qsort (les concepteurs n'ont pas pensé à ajouter un paramètre void *data pour avoir le contexte dans la fonction de tri, etc etc etc..)...

Citation:

---

Envoyé par souviron34

ben non... Quand c'est à l'intérieur du même prog.. Et même quand c'est un autre.. Il ne le reçoit que si il est chargé. Donc il ne change pas de contexte non plus... (en fait le signal est un ensemble(flag+data) dans la partie réservée du système (là où sont les COMMON fortran et les Psect assembleurs, comme les sémaphores).

Mais même si c'était géré par l'OS "roulant", aucun des 2 progs ne changent de contexte.....

---

Euh... Il y a forcément un changement, non?
La fonction de traitement du signal du processus destinataire, elle s'exécute bien dans son contexte à lui, non ?
(je crois qu'on n'utilise pas le terme "contexte" dans le même sens ici...)

Citation:

---

oui ça c'est faux, puisque tu descends à la micro-seconde avec les timers...
Je ne connais pas les threads, mais j'imagine qu'on ne doit guère pouvoir descendre en-dessous...

---

Euh, je n'ai pas tout compris là... Quelle partie est fausse exactement ?

Et puis, je ne suis pas sûr que tu puisses vraiment descendre à la micro-seconde sur un Linux non temps-réel (sous Windows, les paramètres sont en millisecondes et un windows non-embarqué a une granularité interne d'environ 15ms)). Il faut faire une différence entre la résolution du paramètre accepté et ce dont est capable le système...

Citation:

---

Envoyé par Médinoc

Euh... Il y a forcément un changement, non?
La fonction de traitement du signal du processus destinataire, elle s'exécute bien dans son contexte à lui, non ?
(je crois qu'on n'utilise pas le terme "contexte" dans le même sens ici...)

---

oui mais pour qu'il la traite il est en train de tourner, donc il est loadé donc il a son propre contexte.... (si c'est suivant ce sens).

Et encore une fois, pour un timer, c'est au sein du même processus...

Citation:

---

Envoyé par Médinoc

Euh, je n'ai pas tout compris là... Quelle partie est fausse exactement ?

---

la granularité plus fine...

Citation:

---

Envoyé par Médinoc

Et puis, je ne suis pas sûr que tu puisses vraiment descendre à la micro-seconde sur un Linux non temps-réel (sous Windows, les paramètres sont en millisecondes et un windows non-embarqué a une granularité interne d'environ 15ms)). Il faut faire une différence entre la résolution du paramètre accepté et ce dont est capable le système...

---

Code:

---

1 2 3

rttimer.it_value.tv_sec = i ; rttimer.it_value.tv_usec = j ; setitimer (ITIMER_REAL, &rttimer, &old_rttimer);

---

je te ressortirais à un moment le man page, mais tu peux le lire directement. Sur TOUT système unixoide (non TR), on précise le nombre de micro-secondes.

La granularité est déterminée par CLOCKS_PER_SEC je pense....A vérifier.

Mais en tous cas, ça marche parfaitement ....

Pour le timer et processus: Là, je parlais de ton argument sur multi-thread et multi-processus, pas du timer.
Tu es bien forcé d'admettre que lors d'une communication inter-processus par signal, il y a forcément un changement de contexte qui sera plus lourd qu'entre deux threads d'un même processus...

Je ne parlais pas de la granularité en temps (et au passage, je répète: "Il faut faire une différence entre la résolution du paramètre accepté et ce dont est capable le système..."), mais de la granularité de la protection:
Mon niveau actuel de connaissances de Linux ne me permet pas de couper SIGALRM pour un passage tout en laissant pour ailleurs. Un mutex protège des morceaux précis de code, et non pas tout le handler d'un coup...

Je me permet de faire remonter ce post car j'ai le même genre de problème.
Je dois appeler des fonctions avec un intervalle de temps défini.
Le problème c'est que cette intervalle est de l'ordre de la microseconde (jusqu'à secondes).
Si j'ai bien compris je dois utiliser un multithread.
Un pour chaque période,je suppose.
Le problème que je me pose c'est :
Est-ce que le multithread est adapté à mon problème du fait de la rapidité d'execution des taches?

Je ne sais pas si tu peux obtenir un intervalle si petit sur un système non-temps-réel...

C'est bien ce que je pensais.
On peut avoir quel genre d'intervalle?
As-tu un ordre de grandeur par hasard?
Si c'est en millisecondes ca pourrait quand même être interessant je pense.
Sinon j'ai bien eu l'idée de faire un RDTSC,mais j'ai un problème dessus,peut-être l'ordre de grandeur
je sais pas ce qui est le mieux pour cette application, si tu as une idée ca serait bien gentil

Citation:

---

Envoyé par Sylar44

Je me permet de faire remonter ce post car j'ai le même genre de problème.

---

Peu importe, ce n'est pas ta discussion, tu es donc un squatter. Caÿ mal. Tu dois créer une nouvelle discussion si tu n'as pas eu de réponse en lisant le fil.

désolé j'avais pas envie d'être pris pour un squatteur.
Mais j'avais pas envie,non plus, qu'on me dise que ce sujet(que je trouve très proche au mien) est la réponse à mon problème

Citation:

---

Envoyé par Sylar44

désolé j'avais pas envie d'être pris pour un squatteur.
Mais j'avais pas envie,non plus, qu'on me dise que ce sujet(que je trouve très proche au mien) est la réponse à mon problème

---

Peu importent tes envies, seul le bon sens et la logique priment.

• Soit tu as la réponse et tu n'as pas besoin de poser de question
• Soit tu ne l'as pas et dans ce cas, tu crées un nouveau sujet. C'est aussi simple que ça.