Discussion :

[jalber11]

Bonjour à tous,

je viens de créer un programme en utilisant des threads, avec la bibliothèque pthread.h

Je me demandais si il était possible de rendre un thread périodique, pour le moment j'ai juste fait une boucle du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
while(!FIN){
        sleep(TEMPS_ATTENTE);
        sem_pos(&mon_semaphore);
}

et dans mon thread en question :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void code_MonThread(void){
        //initialisations
        while(!FIN){
                sem_wait(&mon_semaphore);
                //actions
                sem_pos(&mon_semaphore);
        }
}

J'ai fait un peu de programmation sur Linux RTAI et on avait une fonction comme celle la : rt_task_make_periodic je me demandais donc s'il existait la même chose si on travaille pas avec un OS temps réel.

Merci d'avance!

[Obsidian]

Hello,

Je ne sais pas s'il existe une fonction explicite pour cela tu peux utiliser alarm() pour demander à être explicitement réveillé dans n secondes, couplé à pause() pour te mettre en sommeil jusqu'à réception d'un signal.

Inconvénient : il faut mettre explicitement un gestionnaire de signal sur SIGALRM sous peine de se faire tuer son processus, et pause() peut être réveillé par un autre signal. Il faudra donc traiter ce cas.

Quoiqu'il en soit, le mieux reste de réarmer alarm() dans le gestionnaire de signal pour pouvoir être réveillé à intervalles réellement fixes quelque soit la durée de la tâche, même si celle-ci dépasse l'intervalle en question.

L'avantage, en revanche, est que tout cela peut tenir en une ou deux fonctions simples, et qu'en t'appuyant sur le système, tu t'affranchis des interactions entre threads et de l'utilisation de sémaphores ou de mutexes.

[jalber11]

Merci pour ta réponse Obsidian; après m'être replongé dans mes codes temps réel j'ai vu que cette fonction appartenait à la bibliothèque rtai_sched.h donc je suis allé voir dans le sched.h normal mais il n'y a rien qui ressemble.

La technique que tu m'indiques me convient parfaitement, donc merci!
Par contre qu'est ce que tu entends par un gestionaire de signal? Ca serait une autre tâche qui lit tous les signaux envoyés pour n'activer que les destinataires des signaux et pas les autres c'est ça?

Quoiqu'il en soit, le mieux reste de réarmer alarm() dans le gestionnaire de signal pour pouvoir être réveillé à intervalles réellement fixes quelque soit la durée de la tâche, même si celle-ci dépasse l'intervalle en question.

Le truc c'est que la périodicité n'est pas critique dans mon application (raison pour laquelle j'utilise pas d'OS temps réel entre autres); et du coup j'aimerais bien que si le processus n'est pas terminé à la fin de l'intervalle de temps voulu, il se termine quand même avant de se relancer, j'imagine que je peux aussi gérer cela dans mon gestionaire de signal non?

Merci pour ton aide en tout cas!

[Obsidian]

Par contre qu'est ce que tu entends par un gestionaire de signal? Ca serait une autre tâche qui lit tous les signaux envoyés pour n'activer que les destinataires des signaux et pas les autres c'est ça?

Non. Les signaux Unix, que tu dois connaître, font partie des fondamentaux du système d'exploitation. Ce sont ceux que tu envoies avec la commande « kill ». Étrangement, ils sont définis non seulement par le standard Unix mais également, et dès le départ, par la norme C ! On les trouve dans C89.

Le gestionnaire de signal, c'est le signal handler, tout simplement. Sous Unix, un signal envoyé à un processus agit un peu comme une interruption logicielle : le processus est préempté par le système, qui lui fait faire un saut obligatoire vers une fonction donnée, quelque soit l'endroit où il se trouve au moment de la réception de ce signal. Cette fonction est justement le gestionnaire de signal qui doit agir en conséquence. Lorsqu'elle se finit, le programme reprend son cours là où il s'était arrêté, exactement de la même façon que lorsque tu appelles une fonction ordinaire.

Au passage, c'est relativement coûteux en temps, ça implique un appel système et une préemption du processus. Le système peut en profiter pour passer la main à un autre. Donc ça doit être occasionnel et ça ne sert pas du tout à faire du message passing comme certains étudiants le pensent parfois. C'est aussi un moyen pour le système de signifier une condition critique à un programme qui lui est extérieure, surtout si le programme n'est pas prévu pour à la base.

Le système peut donc te les envoyer par exemple si un de tes processus fils se termine, si alarm() arrive à échéance ou dans les cas où le système ne peut plus continuer : si un ordre d'interruption quelconque t'a été envoyé (Ctrl-C, extinction de la machine…), si ton programme a déclenché une segfault, si tu écris dans un tube et que le lecteur a refermé ce tube avant que tu aies fini, etc. La liste des signaux est prédéfinie et limitée. Elle ne peut pas être étendue.


Par défaut, et à une ou deux expressions près comme SIGCHLD justement, un signal non pris en charge provoque la mort du processus. Mais tu peux mettre explicitement en place un gestionnaire de signal avec les fonctions signal() et sigaction(), faisant en sorte que ce soit ta fonction qui soit appelée lors de la réception d'un signal plutôt que suivre le comportement par défaut. À noter qu'il existe les macros SIG_IGN et SIG_DFL, servant respectivement à ignorer le signal et à rétablir le comportement par défaut.

Le truc c'est que la périodicité n'est pas critique dans mon application (raison pour laquelle j'utilise pas d'OS temps réel entre autres); et du coup j'aimerais bien que si le processus n'est pas terminé à la fin de l'intervalle de temps voulu, il se termine quand même avant de se relancer, j'imagine que je peux aussi gérer cela dans mon gestionaire de signal non?

Oui, mais pas de la façon dont tu l'entends. La solution que je te propose ne consiste pas à donner une instruction au système pour qu'il fasse renaître un nouveau thread à chaque intervalle, mais à faire en sorte que le même thread se mette en sommeil et soit réveillé au bon moment, à intervalles réguliers.

Donc, si tu veux que ton processus se termine et se relance, il faudra là encore écrire un dispositif spécial.

Merci pour ton aide en tout cas!

À ton service.

[jalber11]

Les signaux Unix, que tu dois connaître

Héhé ben non je connaissais pas En fait j'ai plus l'habitude de programmer sur des microcontrolleurs donc dans ce cas on peut utiliser des interruption timer ou autres (qui finalement se rapprochent pas mal des signaux d'après ce que j'ai compris).

Finalement j'ai utilisé la fonction setitimer() et ça marche bien donc je vais passer le sujet en résolu ^^

En tout cas merci pour tous les conseils ça m'a donné l'occasion de potasser des choses que je maîtrisais pas forcément!