Comment BIEN gérer des threads?

Bonjour,

Voila, une réponse pas évidente à trouver sur le net, puisqu'elle dépend à mon avis beaucoup du type de programme que l'on désire réaliser.

J'aimerai connaître la manière d'aborder l'architecture d'un programme multitâches.

Pour exemple simple, je souhaite réaliser un programme capable de gérer une vidéo, tout en jouant une musique, tout en me permettant de tchatter sur internet. On se rend immédiatement compte, que c'est impossible d'utiliser une seule pile pour toutes ces fonctions.

D'après moi, il faut un thread pour l'interface graphique, un thread pour la lecture de la vidéo, un thread pour la lecture audio et enfin un thread pour les communications réseaux.

Mais je préfère demander l'avis de personnes plus informées que moi sur le sujet, car j'ai peur de vouloir créer trop de thread et d'alourdir mon application plus qu'autre chose.

Enfin, sachant que je travaille avec l'API Windows, auriez vous des conseils à me prodiguer pour faire un programme facilement soigné et facilement retouchable?

Je te conseille de lire les articles de Herb Sutter sur le multithreading et les Actives Objects

Bonjour,

Citation:

---

Envoyé par klakman

Comment BIEN gérer des threads?

---

Pour tenter de répondre à cette question, des gens ont écris des milliers de pages, et des professeurs donnent des milliers d'heures de cour.
C'est une façon de dire que c'est impossible de répondre à cette question, telle quelle, sur un forum.

Citation:

---

Envoyé par klakman

J'aimerai connaître la manière d'aborder l'architecture d'un programme multitâches.

---

Les threads sont un sujet très délicat. Moi je conseille toujours d'en utiliser le moins possible, même pour un développeur chevronné.
Il faut donc avoir une bonne vue d'ensemble de ton programme pour savoir déjà à quel endroit tu risque d'avoir besoin d'utiliser un thread.
Ensuite, commencer à implémenter, et essayer de voir si, à chaque endroit où peut-être il faut utiliser un thread, voir si on ne peux pas s'en passer, en particulier en utilisant les fonctionnalités de l'api sur laquelle on se base. Il est effectivement très important de connaitre un minimum l'api de base pour bien l'utiliser.
Bref, il est extrêmement difficile de décider si on va avoir besoin d'un thread ou pas avant d'avoir un minimum de détails sur l'implémentation (et les évolutions).

Citation:

---

Enfin, sachant que je travaille avec l'API Windows, auriez vous des conseils à me prodiguer pour faire un programme facilement soigné et facilement retouchable?

---

Moi je te conseille de ne pas utiliser l'API windows, mais plutôt une lib faite pour ça, comme par exemple la surpuissante SFML de Laurent Gomilla.

Merci pour vos réponses.

J'ai déjà commencé à lire des choses sur les threads, mais comme je le disais, c'est souvent pour un cas précis, et difficilement adaptable à un autre projet ( d'où ma question ).

Pour la SFML, je crains de ne pas avoir le temps de me lancer tout de suite dans l'apprentissage d'une nouvelle bibliothèque. Néanmoins pourrais tu me donner une précision sur la distribution du programme avec cette librairy? J'utilisais la très simple et cependant robuste Qt4, mais pour la distribution du programme, il fallait une ribambelle de DLL un peu pénible...

Avec la SFML, il suffit d'ajouter 4 ou 5 dlls avec ton exécutable et ça roule.
Un exemple d'appli santd alone (pas d'installation à faire: du dézippe puis tu lances l'exe) développée avec la SFML: http://sourceforge.net/projects/audiogrid/files/
Si lu lances l'appli, c'est la touche escape pour quitter.
Et si tu veux regarder les sources, le dépôt svn est: https://audiogrid.svn.sourceforge.net/svnroot/audiogrid

Ok, dans ce cas là c'est comme pour Qt, et c'est un peu pénible pour une petite appli de transporter un tas de DLLs qui comportent 90% de fonctions non utilisées.

Mais pour une plus grosse application, il est clair que le gain de temps coté programmation, plus le support cross plateform rend l'utilisation de ce type de bibliothèques ( framework ) largement positive!

En tout cas, merci pour les informations.
Je laisse le post ouvert, si quelqu'un veut rajouter des informations.

Citation:

---

Ok, dans ce cas là c'est comme pour Qt, et c'est un peu pénible pour une petite appli de transporter un tas de DLLs qui comportent 90% de fonctions non utilisées.

---

SFML est découpée en 5 modules bien distincts, tu n'auras à distribuer que les modules que tu utilises. En plus il est possible de lier statiquement, la licence est très permissive (zlib/png).
A part ça, je ne vois pas bien le rapport entre SFML et ta question initiale concernant les threads.

Citation:

---

Envoyé par klakman

D'après moi, il faut un thread pour l'interface graphique, un thread pour la lecture de la vidéo, un thread pour la lecture audio et enfin un thread pour les communications réseaux.

Enfin, sachant que je travaille avec l'API Windows, auriez vous des conseils à me prodiguer pour faire un programme facilement soigné et facilement retouchable?

---

Oui et non parce que si tu lis un fichier son ( par exemple un .wav) c'est la carte son qui s'en occupe ; par exemple l'API SndPlay délègue cela à la carte son.
Ou bien avec Direct Sound tu crées un DirectSoundBuffer c'est encore une fois la carte son et son accélération matérielle qui va gérer cela donc inutile de créer un thread pour jouer un son
Sauf si tu veux faire du traitement en temps réel /échantillonage du fichier son ( comme dans SoundForge ou Audacity)
Pour la vidéo c'est pareil..

Citation:

---

Envoyé par Laurent Gomila

SFML est découpée en 5 modules bien distincts, tu n'auras à distribuer que les modules que tu utilises. En plus il est possible de lier statiquement, la licence est très permissive (zlib/png).
A part ça, je ne vois pas bien le rapport entre SFML et ta question initiale concernant les threads.

---

comme si tu connaissais SFML...

Ah ? tu connais ? :)

(ca faisait longtemps que je ne t'avais pas croisé ici !)

Pour l'OP : le nombre de thread que tu pense devoir géré n'est limité que par ton architecture matérielle et par tes besoins en architecture logicielle. De toute façon, sur un système avec N thread hardware (2 fois le nombre de coeur, généralement), il n'est pas conseillé d'allouer plus de N thread. Mais dans le mêmen temps, ton OS va en utiliser un très grand nombre (50, 100...) alors a moins d'avoir un véritable besoin de performance et de prouver que le switch de contexte entre thread pose un véritable problème (ou que les thread ont un quantum de temps trop faible pour s'exécuter correctement), il est préférable de favoriser l'architecture logicielle a l'arcitecture matérielle.

Ensuite, effectivement, la gestion des threads depends de tes besoins particuliers. Deux programmes ne vont pas les utiliser de la même manière. Deux programme de même genre vont peut être fonctionner de manière totalement différente.

Il n'y a pas de bonne réponse à ta question - mais c'est une bonne question quand même :)

Merci pour cette réponse claire.

En effet j'avais déjà entendu parler de limiter le nombre de thread du programme par rapport à l'architecture matérielle. Mais comme tu le dis bien, et comme je ne souhaite pas privilégier les performances pour le moment ( programmes peu gourmands ) je vais plus me concentrer sur l'architecture logicielle.