Discussion :

[kekeboy]

Bonjour tout le monde,

Je sais pas si mon intitulé est exact Mais ce serait pour un renseignement.

J'ai quelques bases en C et pour un stage je dois concevoir un programme.

Le probleme est que j'aimerais creer des sous programmes qui tournent independament les uns des autres, cad qu'il n'y ait pas une lecture lineaire dans mon programme principal.

J'aimerais savoir en outre, si les pointeurs peuvent faire circuler des valeurs dans les memoires et les échanger entre les sous programmes.

Je sais pas si je me suis bien fait comprendre alors je vais vous faire un petit exemple:

Admettons que j'ai mon pogramme contenent 2 sous-programmes, l'un bouclant 10 fois et l'autre 20 fois. Si j'ai une lecture lineaire le programme va faire tourner le premier sous programme 10 fois puis l'autre 20 fois. Moi j'aimerais que les 2 tournent en meme temps, donc le premier finirait de boucler avant le second (en admettant qu'ils aient les memes durees d'applications).

Merci bien de m'aider si vous le pouvez ^^

PS, j'ai la bible du C/C++ chez moi si ca peut m'aider

[JolyLoic]

Bonjour tout le monde,

Je sais pas si mon intitulé est exact Mais ce serait pour un renseignement.

J'ai quelques bases en C et pour un stage je dois concevoir un programme.

Si tu programmes en C, ne serait-il pas plus judicieux de poster sur le forum C ?

Le probleme est que j'aimerais creer des sous programmes qui tournent independament les uns des autres, cad qu'il n'y ait pas une lecture lineaire dans mon programme principal.

Le terme sous-programme est rarement utilisé, en C comme en C++. On parlera plus facilement de fonction.

Ce que tu cherches c'est ce qu'on nomme généralement du multi-thread (voire du multi-process). C'est un concept qui n'est pas défini en C++, aussi dois-tu te reposer sur des fonctions spécifiques à ton environnement de travail.

J'aimerais savoir en outre, si les pointeurs peuvent faire circuler des valeurs dans les memoires et les échanger entre les sous programmes.

En règle générale, quand on fait du multi-thread, la mémoire est partagée entre les différents threads d'exécution. Qu'il s'agisse de mémoire gérée par pointeurs ou non. Par contre, attention, celà implique que plusieurs threads peuvent accèder à la même mémoire en même temps, ce qui pose des problèmes de corruption. C'est une des raisons pour lesquelles programmer en multi-thread est significativement plus complexe que programmer en mono-thread.

PS, j'ai la bible du C/C++ chez moi si ca peut m'aider

Ca peut peut-être t'aider, si tu as une armoire bancale...

[loufoque]

Sinon tu peux aussi utiliser les coroutines, ce qui est plus performant que les threads et ne pose pas de problèmes de synchronisation mémoire.
Par contre c'est coopératif, pas préemptif.

Ou alors tu peux ré-écrire ton programme de manière à ne pas avoir besoin de parallelisme.

[Pragmateek]

Ou alors tu peux ré-écrire ton programme de manière à ne pas avoir besoin de parallelisme.

En effet car le multi thread a un coût à cause des changements de contexte au niveau du processeur.

[kekeboy]

Salut et merci pour vos commentaires.

En fait les multi-processus semble la solution a mon pb, donc je dis un grand merci a tout le monde et peut a bientot.

PS. je programme sur C++ ^^

[loufoque]

Tu fais un concours de PS sans intérêt ?

[mat.M]

Salut et merci pour vos commentaires.

En fait les multi-processus semble la solution a mon pb, donc je dis un grand merci a tout le monde et peut a bientot.

PS. je programme sur C++ ^^

Tout dépend de l'OS ; si c'est sous Unix il ya des biblios pour cela.
Sous Windows utiliser des API comme CreateThread,_beginthread

[Médinoc]

Sauf que pour Windows tu donnes des solutions multi-thread et non pas multi-processus, et que non, _beginthread() n'est pas une solution. _beginthread() est un problème : _beginthreadex() est une solution.

• Multithread pour Windows : CreateThread() ou _beginthreadex() (préférer la seconde).
• Multithread sous Unixoïde : La bibliothèque C la plus courante, c'est pthread. En C++, je crois bien qu'il y a boost.thread.
• Multiprocessus sous Windows : CreateProcess() ou ShellExecuteEx().
• Multiprocessus sous Unixoïde : fork() [ +exec() ]

[Startux]

loufoque à dit :
Sinon tu peux aussi utiliser les coroutines, ce qui est plus performant que les threads et ne pose pas de problèmes de synchronisation mémoire.
Par contre c'est coopératif, pas préemptif.

Dites-moi si je me trompe mais on parlait de thread classique en multi taches, mais la préemption concerne le temps réel. Si on n'utilise pas de thread temps réel les threads fonctionnent en round robin de façon naturel non ?.
Au fait c'est quoi "coopératif" ?

---

Un travail de groupe est un travail où chacun à son poste qui lui plaise ou non

[Médinoc]

Le "multitâche coopératif", à ce que j'ai compris (source Wikipédia FR), c'est le principe de Win 3.1 : Un seul thread, dans lequel tournent toutes les fenêtres. Les applications doivent rendre d'elle-même le processeur au système (généralement, au return de la WindowProc()).

Le multitâche préemptif, depuis les mêmes sources passées par le même cerveau, c'est le contraire: C'est le kernel qui dit "Le processeur à tel thread, maintenant!". C'est le cas sous Windows depuis le début de Win32.

Donc non, il semblerait que préemption et temps réel ne soient pas équivalents.
De plus, il y a un autre terme de "préemption" employé dans "Inside Windows 2000", qui désigne le concept d'un thread de priorité supérieure se réveillant pour n'importe quelle raison et prenant d'office le processeur à un thread de priorité inférieure.

[loufoque]

(source Wikipédia FR)

Pour tout ce qui est informatique Wikipédia EN est bien plus intéressant et surtout plus complet.

En tant que programmeur windows, tu as peut-être déjà entendu parler des "fibers" ?

[Médinoc]

Oui, elles sont apparues sous XP, et c'est un peu une nouvelle forme de multitâche coopératif.

Mais franchement, je trouve cela inutile et pense que ça risque plus de compliquer le code qu'autre chose.

[loufoque]

Mais franchement, je trouve cela inutile et pense que ça risque plus de compliquer le code qu'autre chose.

Ça ne pose pas les problèmes de performance du multithreading ni les problèmes de synchronisation (deadlocks etc.)

[Médinoc]

Forcément, puisque tout s'exécute séquentiellement.

Il faudrait sans doute que je me penche plus avant dessus, mais je trouve que ça complique plutôt que de simplifier par rapport à un code séquentiel normal.