Sous programmes independants dans le programme principal

Version imprimable

09/07/2006, 01h15
kekeboy

Sous programmes independants dans le programme principal

Bonjour tout le monde,

Je sais pas si mon intitulé est exact :P 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
09/07/2006, 01h42
JolyLoic

Citation:

Envoyé par kekeboy

Bonjour tout le monde,

Je sais pas si mon intitulé est exact :P 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 ?

Citation:

Envoyé par kekeboy

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.

Citation:

Envoyé par kekeboy

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.

Citation:

Envoyé par kekeboy

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...
09/07/2006, 03h50
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.
09/07/2006, 12h45
Pragmateek

Citation:

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.
10/07/2006, 01h56
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++ ^^
10/07/2006, 02h19
loufoque

Tu fais un concours de PS sans intérêt ?
10/07/2006, 15h15
mat.M

Citation:

Envoyé par 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++ ^^

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
10/07/2006, 15h20
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() ]
10/07/2006, 15h50
Startux

Citation:

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 ?.
:fou: Au fait c'est quoi "coopératif" ?

---
:lahola:
Un travail de groupe est un travail où chacun à son poste qui lui plaise ou non
10/07/2006, 15h59
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.
10/07/2006, 16h12
loufoque

Citation:

(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" ?
10/07/2006, 16h20
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.
10/07/2006, 16h39
loufoque

Citation:

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.)
10/07/2006, 16h47
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.