Réponse - Informaticien.be

Poster une réponse à un sujet: Les threads, c'est mal?

Attention, ce sujet est un sujet ancien (6828 jours sans réponse)

forum_emoticons.html

Courriel [email=nobody@nobody.org]Nom[/email]

Lien [url=http://www.website.com]Texte[/url]

Image [img]http://www.website.com/image.jpg[/img]

Aligné à gauche [align=left]Texte[/align]

Aligné à droite [align=right]Texte[/align]

Toute la largeur [align=justify]Texte[/text]

Mise en forme [highlight=pascal]Texte[/highlight]

Liste [list=square][item]BlaBla[/item][/list]

Liste Numérotée [list=decimal][item]BlaBla[/item][/list]

Spoiler [spoiler]James est le meurtrier![/spoiler]

Tout en majuscules [uppercase]Texte[/uppercase]

Tout en minuscules [lowercase]Texte[/lowercase]

[quote=philfr,21825]Bon, ben comme je ne développe ni avec Delphi et encore moins sur W32 je suis prêt à mettre des limites à mon affirmation par manque de connaissances. 
Mais comme le post initial parlait des Posix threads, je suppose qu'il ne s'agit pas de W32 (encore que je puisse me tromper sur ce point là également)

Ce disclaimer étant établi, voici mon point de vue résumé:

- les threads permettent de résoudre un problème de concurrence en n'y réfléchissant pas: on développe chaque thread comme s'il était tout seul et c'est bien parce que c'est facile;
- on se trouve très vite confronté au problème de l'accès partagé à des données (ou à toute autre chose partageable, comme du hardware pour ceux qui comme moi font de l'embarqué), et toutes les implémentations de threads apportent une solution, avec des mécanismes de synchronisation (mutex, sémaphores, variables de condition, ...) qui sont assez simples, en apparence en tout cas;
- on développe son système, on le teste au fur et à mesure de son développement, et tout va bien, jusqu'au jour où on le met en production, que la charge augmente, et que des bugs inconnus à ce jour apparaissent mystérieusement;
- on se rend compte que les mécanismes de synchronisation ne sont pas si simples, et surtout qu'ils ne peuvent pas être testés de façon exhaustive. Les conditions de course sont très rarement reproductibles de façon systématique;
- le comportement d'un système thread-based ne peut pas être facilement prédit par la lecture de son code (un comble !) car ce comportement se trouve plus dans les interactions entre composants que dans chaque composant individuel;
- ma conclusion troll: si j'ai un problème de concurrence et que j'utilise des threads pour le résoudre, je me retrouve avec deux problèmes au lieu d'un.

Les seuls problèmes qui peuvent être résolus simplement et élégamment par des threads, sont les problèmes où les threads n'interagissent pas (ex: un long calcul RSA dans son coin jusqu'à rendre la réponse, pendant ce temps le reste du programme continue à réagir à l'utilisateur)

Pour la plupart des autres cas, où ce que l'on veut est un programme qui réagit à beaucoup d'inputs possibles, mais qui autrement passe le plus clair de son temps à attendre ces inputs, le ractor pattern est bien plus approprié. Son utilisation se fait en général avec une librairie "callback-based", où les APIs ne sont jamais bloquants, mais auxquels on passe un pointeur de fonction à appeler quand le résultat est disponible. L'implémentation en Unix se fait en passant par le system call select() ou poll() qui permet d'attendre simultanément sur plusieurs file descriptors, et de traiter en série les événements au fur et à mesure de leur arrivée.
Si l'application n'est pas cpu-bound, la réactivité sera toujours meilleure avec ce genre d'architecture qu'avec un système threadé (le scheduling lui-même apporte un overhead pour le cpu). L'occupation de ressources (mémoire) est également bien plus faible en général.

La courbe d'apprentissage des threads est rapide, et c'est son danger parce qu'il faut beaucoup d'expérience pour développer correctement avec des threads, et encore plus pour débugger quand ça ne va pas, alors qu'un programmeur débutant a l'impression de suite de comprendre ce qu'il fait tant qu'il est dans son thread.
La courbe d'apprentissage d'une librairie event/callback-based est plus lente, juste parce que les langages ne sont pas conçus avec ce paradigme. Avec un langage OO de haut niveau (qui a dit python ?), en peut rendre la chose presque naturelle. En C (et j'ai développé un tel framework), un certain nombre de problèmes persistent, mais le développement est néanmoins incroyablement plus rapide et moins bug-prone (le management a d'ailleurs fini par me croire sur ces points). Les problèmes qui subsistent sont ceux inhérents au C (allocation de mémoire et pointeurs).

Voilà, j'arrête ici pour l'instant, parce qu'il y a sûrement d'autres réactions entre temps...[/quote]

antp

Citation de: zion

Pour éviter la fragmentation de ton disque, j'alloue un stream de la taille direct du fichier, 2GB. La création du fichier va prendre plusieurs secondes.

Seulement en FAT32.
En NTFS c'est immédiat normalement (enfin, ça l'était quand j'ai testé).

Sinon pour l'histoire de la fragmentation, même si avec d'autres FS ça fragmente moins il y a des cas où ça fragmente.
Si tu remplis ton fichier, à 100 Mo t'arrives à la fin de la zone libre, tu continues ailleurs. Il va pas bouger les 100 Mo pour passer à 101 Mo contigus. Alors que si dès le début il sait que ça va faire 2 Go il peut attaquer une zone libre de plus de 2 Go.

philfr

Ben, oui, j'allais dire....
Google est un software pour monsieur tout le monde aussi, mais c'est pas développé sous Windows...

zion

Altar> Ca m'arrive plus vraiment, le seul soft pour monsieur tout le monde que je faisais, c'est fini. Mais il m'arrive de devoir faire des progs pour des clients sous Windows en effet :smile:

Altar

Citation de: philfr

Et Windows, c'est important pour toi ? :wink:

Et quand on code des softwares pour monsieur tout le monde, je dirais qu'il est risqué de se priver de 95% du marché. Enfin ce n'est que mon avis :ddr555:

zion

Pour le moment oui, vu que Kylix est assez mauvais comme environnement de dev sous Linux, il n'arrive pas à la cheville de Delphi 7 (y a pleins de soucis dans la gestion des raccourcis). (Puis y a des petits détails et logiciels qui me manqueraient trop :sweat:

)

philfr

Et Windows, c'est important pour toi ? :wink:

zion

Oui, mais tu vois... les threads c'est important sous Windows :ddr555:

philfr

Bah, moi j'utilise un vrai OS, et la fragmentation je ne connais pas :tinostar:

Un fichier chez moi, c'est un truc que j'ouvre, dans lequel je peux lire et écrire, que je ferme, et que je peux rouvrir plus tard pour faire la même chose.
Comme mes connexions TCP pour lesquelles je n'ai pas à me soucier des timeouts ou des MTU...

zion

Si je ne connais pas la taille tant pis, j'augmente la taille du fichier au fur et à mesure, mais ca augmente largement la fragmentation au niveau du disque.

Ce serait en effet sympa que l'OS se démerde de ce côté, mais si il faut 10s pour créer le fichier et que la ligne suivante tu veux écrire dans le fichier, t'es baisé :joce:

A moins évidemment que l'écriture dans le fichier soit bloquée par l'OS jusqu'à ce qu'il soit réellement crée, mais alors il a intérêt a avoir un sacré buffer si tu commences à écrire comme un sauvage... :ddr555:

philfr

Dans les frameworks asynchrones, aucun API n'est bloquant, et tout ceux qui renvoient un résultat le font via un callback ou un event.

Quant à ton problème de préallocation de disque et de fragmentation, c'est dommage que tu doives t'occuper de ce genre de choses dans une application non ? Pour moi c'est le rôle de l'OS de faire le concierge :oh:

.
Quid si ton fichier est stocké sur le réseau ? Ou si tu ne sais pas quelle taille il aura avant de le charger ?