questions sur les Thread [Débutant] - C++ - Programmation
Marsh Posté le 21-05-2006 à 21:24:13
Amonchakai a écrit : 1) c'est au sujet des CRITICAL_SECTION bon j'ai compris comment on les utilise pour que chacun des threads attendent que l'un est fini pour qu'un autre fasse une action. Mais imaginons que nous avons trois champs :
|
Ce que tu appelles champs, ce sont des variables selon le langage courant, des objets selon la norme. Ces variables ont une classe de stockage, et selon celle-ci, elles peuvent être partagées ou non par différents threads. (Note que C++ ne connait rien des threads, donc c'est entièrement dépendant de l'implémentation, et vu que tu ne la précises pas, on ne peux pas en dire bien plus).
Défini ce que tu veux dire par "groupé".
Citation : et ensuite dans nos threads on fait EnterCriticalSection() et LeaveCriticalSection(). |
Tu peux faire 3 sections critiques consécutives, ou une seule, du moment que tu protèges la lecture/ecriture de tes objets partagés par les threads. Je crois qu'il est bon de minimiser le nombre et la taille des sections critiques, mais il faut surtout s'assurer en priorité que la synchronisation est correcte. Les erreurs de ce genre sont quasi impossibles à reproduire, et le debugage est ignoble.
Citation : 2) Sinon j'avait lu qu'il fallait éviter d'utiliser les champs pour syncroniser les threads. C'est donc cette méthode avec les critical_section qu'il faut éviter de faire pour la syncronisation c'est ça ? |
?
Citation : 3) D'un point de vue mise en forme, quand on crée un object on déclare l'object dans un header et on met les definitions des methodes dans un .cpp. Pour les threads y a t'il une convention ? (si bien sûr s'il n'est pas dans un object, sinon pas de problèmes). |
... quand on crée une classe, on la définie dans un header, on déclare donc les fonctions membres dans le header, et on les défini
dans le .cpp. Pour les conventions, je ne sais pas, c'est très religieux ce genre de truc.
Citation : 4) Quand a l'utilisation d'un thread, on m'avait dit qu'il ne fallait confier a des threads que des petites taches pas trop lourdes comme par exemple gérer une horloge qui envoie des message toutes les X secondes. Vous confirmer ??? |
Non.
Marsh Posté le 22-05-2006 à 14:37:53
tout d'abord Merci de m'avoir répondu !!!
Bon tout d'abord je disait "champ" a la place de "variable" parce que l'on m'avait dit qu'il fallait dire "champ" et non pas "variable" (en java) alors moi bête et méchant...
Sinon ce que je voulais dire par "groupé" c'est en fait que pour une quelconque action on aurrait toujours besoin d'utiliser les 3, disons que les trois sont indissotiable. Donc je me disai dans ce cas là il n'y arrait besoin que d'une seule CRITICAL_SECTION que l'on arrait a regarder avant de pouvoir acceder aux 3 variables (au lieu de créer une CRITICAL_SECTION pour pour chacune des variables). Mais là n'était pas vraiment ma question, c'était quand on a besoin que d'une des trois variable, il faut donc bien créer une CRITICAL_SECTION par variable? Pour ce qui est de l'implémentation que j'utilise c'est l'API Win32 (enfin je pense que c'est ça que tu me demande...)
en tout cas Merci de ta réponse
Marsh Posté le 22-05-2006 à 21:50:07
Amonchakai a écrit : Bon tout d'abord je disait "champ" a la place de "variable" parce que l'on m'avait dit qu'il fallait dire "champ" et non pas "variable" (en java) alors moi bête et méchant... |
Qu'est-ce qui s'appelle champ en java ?
Citation : Sinon ce que je voulais dire par "groupé" c'est en fait que pour une quelconque action on aurrait toujours besoin d'utiliser les 3, disons que les trois sont indissotiable. |
Tu pourrais peut être en faire une classe, qui aura pour rôle de maintenir l'éventuel invariant entre les 3 variables, ainsi que de traiter "d'un seul coup" la modification (ou l'affectation) de ces 3 variables. C'est une idée, je ne suis pas sur que ce soit applicable dans ton cas.
Citation : Donc je me disai dans ce cas là il n'y arrait besoin que d'une seule CRITICAL_SECTION que l'on arrait a regarder avant de pouvoir acceder aux 3 variables (au lieu de créer une CRITICAL_SECTION pour pour chacune des variables). |
Une seule section critique suffit, pourvu que la modification et l'acces à ces 3 variables soit dans une section critique.
Citation : Mais là n'était pas vraiment ma question, c'était quand on a besoin que d'une des trois variable, il faut donc bien créer une CRITICAL_SECTION par variable? |
Si tu n'a besoin que d'une des trois variables à modifier ou à accéder, tu la met dans une section critique, pour la protéger de l'acces et de la modification de cette vairable par les threads concurrents -- comme dans le cas précédent.
Marsh Posté le 20-05-2006 à 14:44:16
Bonjour, bon ça fait deux jours que j'ai commencé a apprendre a utiliser les threads donc je sais les créer, les syncronisers... Mais je me pose quelques petites questions :
1) c'est au sujet des CRITICAL_SECTION bon j'ai compris comment on les utilise pour que chacun des threads attendent que l'un est fini pour qu'un autre fasse une action. Mais imaginons que nous avons trois champs :
Donc si j'ai bien compris si on veut partager ces trois champs entre tous nos threads, et que l'on sait qu'ils vont toujours rester groupé il faut créer une section critique comme par exemple :
et ensuite dans nos threads on fait EnterCriticalSection() et LeaveCriticalSection().
mais si les trois s'utilisent indépendament il faut créer une section critique par champ ??? (si c'est ça c'est pas très pratique non ?).Et en plus se sera à chaque fois à nous de faire le lien entre le champ que l'on veut utiliser et sa section critique... Donc c'est vraiment comme ça que ça s'utilise ?
2) Sinon j'avait lu qu'il fallait éviter d'utiliser les champs pour syncroniser les threads. C'est donc cette méthode avec les critical_section qu'il faut éviter de faire pour la syncronisation c'est ça ?
3) D'un point de vue mise en forme, quand on crée un object on déclare l'object dans un header et on met les definitions des methodes dans un .cpp. Pour les threads y a t'il une convention ? (si bien sûr s'il n'est pas dans un object, sinon pas de problèmes).
4) Quand a l'utilisation d'un thread, on m'avait dit qu'il ne fallait confier a des threads que des petites taches pas trop lourdes comme par exemple gérer une horloge qui envoie des message toutes les X secondes. Vous confirmer ???
en tout cas Merci a ceux qui me répondront