Discussion :

[LegendOfYoda]

Bonjour à tous,

n'étant pas spécialisé developpement, je code comme je peux en C++, mais comme à mon habitude j'ai un profonde aversion pour le "faire sans comprendre".

BREF!

Mon programme permet de contrôler plusieurs matériels différents, comme un laser, un système de translation et quelques bricoles. Je dis envoyer toutes les Xms un signal à une machine pour lui dire qu'elle peu fonctionner, si je ne le fais pas, elle s'arrête totalement (sécurité en cas de plantage).

Pour se faire, j'avais entendu parler des threads. Mais quel est leur fonctionnement exact?

J'avais compris que l'on pouvait faire tourner 2 fonctions en parallèle, et en même temps, mais ayant tenté d'implémenter un QThread, je me suis rendu compte que ça n'étais pas le cas.(1) Sur wikipédia, l'image me présente un autre modèle ( https://fr.wikipedia.org/wiki/Thread_(informatique)) qui m'explique qu'en effet, on fait tourner 2 fonctions en parrallèle, mais pas dans le même temps.

ALors comment est ce que ça fonctionne, et qui croire?

Je reste un novice, donc le langage trop évolué.. Euuhhh....

merci à tous

(1) - en gros, j'ai fais tourner une fonction qui prends du temps, et le bit de vie, pourtant transmis via un thread, n'a plus été transmis.

[dalfab]

ALors comment est ce que ça fonctionne, et qui croire?

Les threads sont biens des unités de traitements qui s'exécutent en parallèle. Donc si les threads appellent une même fonction, celle-ci s'exécute simultanément plusieurs fois.
L'article Wikipedia le dit, mais les explications sont parfois un peu floues et les schémas sont mal choisis.
Quant à ton utilisation avec Qt, il faudrait voir plus en détail pourquoi tu y as vu une impossibilité d'avoir une double exécution simultanée.
Si on lance 2 fois les threads composés de la fonction suivante :

Code :

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

1
2
3
4
5
void simple_boucle() {
   for ( int  cnt = 0 ; ; ++cnt ) {
      std::cout << "valeur courante " << cnt << std::endl;
   }
}

On verra qu'il y a deux compteurs qui s’incrémentent indépendamment. On verra aussi le problème de non-réentrance soulevé par Wikipedia car la simultanéité des messages provoque des textes entrelacés quasi-illisibles.

[camboui]

Pour se faire, j'avais entendu parler des threads. Mais quel est leur fonctionnement exact?

Je vais juste donner ma petite réponse à moi

De la même manière qu'un système d'exploitation permet l'exécution de plusieurs processus simultanés (programmes, services, applications, scripts, etc...), un processus peut lui-même faire exécuter plusieurs threads simultanés pour son propre usage. En pratique à un thread on associe une fonction qui s'exécute en parallèle et indépendemment de la fonction principale (i.e. main() en C/C++).
A la différence des processus qui s'ignorent les uns les autres, les threads partagent les ressources allouées à un processus, sauf la pile.

Les threads comme les processus ne sont pas propres à un langage de programmation. C'est une fonctionnalité offerte par le système d'exploitation. Les langages de programmation proposent des syntaxes plus ou moins avancées pour les exploiter, et le C++ n'est pas un champion en la matière.

[LegendOfYoda]

Je vais juste donner ma petite réponse à moi

De la même manière qu'un système d'exploitation permet l'exécution de plusieurs processus simultanés (programmes, services, applications, scripts, etc...), un processus peut lui-même faire exécuter plusieurs threads simultanés pour son propre usage. En pratique à un thread on associe une fonction qui s'exécute en parallèle et indépendemment de la fonction principale (i.e. main() en C/C++).
A la différence des processus qui s'ignorent les uns les autres, les threads partagent les ressources allouées à un processus, sauf la pile.

Les threads comme les processus ne sont pas propres à un langage de programmation. C'est une fonctionnalité offerte par le système d'exploitation. Les langages de programmation proposent des syntaxes plus ou moins avancées pour les exploiter, et le C++ n'est pas un champion en la matière.

Bonjour,

merci pour votre réponse, je comprends mieux. Est-il possible en C++ de faire un équivalent de plusieurs processus en un seul soft? Car j'ai l'impression que lorsque de thread distincts travaillent ensemble, certaines fonctions les bloquent tous, comme le "Sleep(X)" (que je devrais songer à ne plus utiliser d'ailleurs).

L'idée étant d'avoir un thread qui renvois un 1L a une sorties toutes les 250ms quoi que mon programme fasse, sauf que de l'autre coté, je colle des tempos dans une liaison série et quand un Sleep passe, mon bit trepasse!

[dalfab]

Salut,

En aucun cas Sleep() ne devrait bloquer les autres threads. Là encore as-tu un exemple qui te fait penser cela?
Attention a ne pas avoir plusieurs threads qui interagissent avec l'IHM. Par exemple un Sleep() sur le thread principal va le bloquer lui, mais la pompe à message ne sera alors plus gérée et tous les affichages vont figer (mais les threads eux continuent normalement!) Il ne faut utiliser Sleep que sur des threads secondaires.
Et pour exécuter quelque chose à une cadence régulière, il y a les timers qui sont nettement plus simple que les threads.

[LegendOfYoda]

Je vais regarder comment te vous transmettre un exemple, c'est pas si simple! J'uilise Sleep dans ma fonction principable, en gros, c'est une fenête, quand je clique sur "envoyer" je rentre dans une boucle qui fait "envois - sleep - lecture" et c'est à ce moment que ça bloque.

J'utilise timer et thread, le timer lui se boucle avec le reste du programme je l'ai isolé dans un thread pour envoyer mon bit à intervalle régulière.

[foetus]

je rentre dans une boucle qui fait "envois - sleep - lecture" et c'est à ce moment que ça bloque.

C'est plus compliqué que cela

Il faut faire une boucle while tant que "ce n'est pas fini" (soit un envoi d'une commande arrêt, soit le dépassement d'un temps "timeout", soit les 2, soit autre)
Cette boucle va faire des "sleep" avec un delta de temps fixe (delta_time) (10, 15, 20 ... millisecondes)
Et à chaque réveil, il faut incrémenter un compteur temps (count) avec le temps réel du "sleep" (<- tu fais la différence entre le temps réel après et le temps réel avant)
Si ce compteur count dépasse le temps imparti (func_time), tu fais le traitement et tu soustrais func_time à count (<- à adapter)

Et évidement ceci ce ne sont que les gros traits à faire , parque si tu as plus de 2 "threads" (fil d'exécution en français) à gérer il te faudra un tableau ou un "pool"

[dalfab]

c'est une fenête, quand je clique sur "envoyer" je rentre dans une boucle qui fait "envois - sleep - lecture" et c'est à ce moment que ça bloque.

Dans un click donc dans un traitement fenêtre, si on pause le thread tout les affichage vont figer, c'est le cas auquel je pensais.

J'utilise timer et thread, le timer lui se boucle avec le reste du programme je l'ai isolé dans un thread pour envoyer mon bit à intervalle régulière.

Un timer dans un thread, là ça n'a pas vraiment de sens (ou bien je n'ai rien compris à ta phrase). La fonction associée au timer est lancée par Qt indépendamment du thread à partir duquel tu as armé le timer. Utiliser les deux à la fois s'est choisir une complexité inutile (je fais du temps réel depuis 30 ans et ça ne m'est jamais venu à l'idée!)

[d_d_v]

Je vais regarder comment te vous transmettre un exemple, c'est pas si simple! J'uilise Sleep dans ma fonction principable, en gros, c'est une fenête, quand je clique sur "envoyer" je rentre dans une boucle qui fait "envois - sleep - lecture" et c'est à ce moment que ça bloque.

J'utilise timer et thread, le timer lui se boucle avec le reste du programme je l'ai isolé dans un thread pour envoyer mon bit à intervalle régulière.

Bonjour. Une application graphique (Windows ?) ne fonctionne pas de la même manière qu'une appli console.
Sous Qt/Windows, quand l'appli graphique s'affiche, il y a un thread principal avec une boucle de messages qui se charge d'intercepter tous les messages liés au fonctionnement de la fenêtre et de l'appli (mise à jour de l'affichage de la fenêtre, événements souris, clavier, etc.)
Si tu fais un Sleep dans la "fonction principale" (qu'est-ce que tu entends par là), ça va bloquer le fonctionnement de la boucle de messages, et la partie graphique va être figée. En plus le Sleep va à l'encontre de l'intérêt de l'usage d'un thread secondaire.
Il faut:
- depuis une fonction événementielle (par exemple, associée à l'appel d'un menu), lancer le thread secondaire (thread de travail) et ne surtout pas faire de sleep
- dans le thread de travail, faire le travail souhaité, et à la fin de la fonction du thread, envoyer un message (signal pour Qt) à l'appli (donc au thread principal de l'appli) pour lui indiquer que le thread s'est terminé. A ce moment, en fonction de comment c'est implémenté, il peut être nécessaire de faire un close du handle de thread.
Note: le thread ne doit en aucun cas accéder aux éléments de la partie graphique!