de la réponse que vous donnerez à la question va dépendre tout un projet (enfin une partie), alors svp donnez la bonne, celle que je veux entendre
Le problème est simple : je dois gérer 10 processus avec un état pour chaque. J’ai donc créé un tableau d’une structure contenant le PID et l’état. Bref, un beau tableau à 10 cases pour recevoir 10 pid et l’état de chacun (l’état c’est juste un entier).
Je fais mes fork pour créer 10 fils du processus principal (au passage merci m’sieur Rifflet) et je remplis à chaque fois mon tableau avec le PID et l’état de base. Mais j’avais oublié le problème dit « de la réplication de contexte » : chacun des processus doit faire évoluer indépendamment des autres son état dans le tableau.
Et là le bât blesse : si dans un processus je change l’état, je suppose (enfin je sais même) que ce changement ne sera répercuté dans aucun autre processus…bref je fais quoi là?
J’ai pensé à déclarer mon tableau de dix structures en statique, mais je sais pas trop si ça va marcher (j’ai cherché mais je crains bien que non : la « persistance » du static a ses limites). Bref, vais-je devoir refaire tout mon prog en passant aux listes chaînées?
Merci d’avance!
Vivil - déprimé.
edit : bon…le multi-threading c’est bien mais y’a VRAIMENT pas d’autre moyen???
je pense que declarer ton tableau en static devrait marché …
mais je suis vraiment pas sur de moi, ca fait bien longtemps que je n’ai plus fait de C.
Le plus simple ne serait -il pas de tester ca ???
effectivement, j’avais pas du tout pensé aux segmems
Il suffit d’en créer un de la taille que je veux, je l’attache à tous les fils et j’y crée mon tableau…ça devrait convenir pile-poil, et la gestion par tableau possible est plus simple.
Sinon je vais effectivement tenter le static…mais le segmem me paraît de base plus propre.
Merci à vous deux!
Vivil - de toute façon les threads c’était mort le prof en voulait pas…
Argh mais non. Ca c’est pour partager entre processus, pas entre threads. Entre threads c’est sale de faire ca, il te suffit d’avoir dans chaque thread un pointeur vers ton tableau de structure status. Si chacun sait quel est sa place dans le tableau, ils pourront tous y ecrire peinard je vois pas le probleme.
[quote name=‘GloP’ date=’ 27 Jan 2005, 21:02’]Argh mais non. Ca c’est pour partager entre processus, pas entre threads.
[right][post=“326426”]<{POST_SNAPBACK}>[/post][/right][/quote]
Ben en lisant son message j’ai plus l’impression qu’il parlait de processus Unix, non? Alors autant rester dans les IPC…
[quote name=‘GloP’ date=’ 27 Jan 2005, 21:02’]il te suffit d’avoir dans chaque thread un pointeur vers ton tableau de structure status.
[right][post=“326426”]<{POST_SNAPBACK}>[/post][/right][/quote]
Ben je vois pas trop la différence, la mémoire partagée c’est jamais rien qu’une espèce de pointeur vers une zone de mémoire particulière (menfin mes souvenirs de prog système restent quand même assez vagues).
Ha ouai au temps pour moi… fork processus. Sa derniere phrase sur les threads m’en rendu tout confus… J’ai tellement plus l’habitude de faire du multi processus lourd aussi que je suis a la rue. Desolé, il fait bien de dialogue inter process et dans ce cas la il faut la memoire partagee ou du pipe… Groduik wins (Cela dit si tu peux le multi threading c’est souvent mieux :P)
[quote name=‹ GloP › date=’ 27 Jan 2005, 23:06’]Ha ouai au temps pour moi… fork processus. J’ai tellement plus l’habitude de faire du multi processus lourd que je suis a la rue. Desolé, il fait bien de dialogue inter process et dans ce cas la il faut la memoire partagee ou du pipe… Groduik wins (Cela dit si tu peux le multi threading c’est souvent mieux :P)
[right][post=« 326482 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Woot ce post est à garder
[quote name=‹ GloP › date=’ 27 Jan 2005, 23:06’](Cela dit si tu peux le multi threading c’est souvent mieux)
[right][post=« 326482 »]<{POST_SNAPBACK}>[/post][/right][/quote]
[quote name=‹ GloP › date=’ 27 Jan 2005, 23:06’](Cela dit si tu peux le multi threading c’est souvent mieux :P)
[right][post=« 326482 »]<{POST_SNAPBACK}>[/post][/right][/quote]
Justement ce serait tellement simple
Mais nan, le prof veut explicitement du bon gros fork et tout. Donc segmem, très bien, pas obligé de tout recommencer le code. Pour donner une idée, les autres sont partis dans des histoires de pseudo-listes chaînées de structures décrivant l’état d’un processus avec une synchro par signaux.
De toute facon il en aura quand meme besoin pour empecher les process de se marcher dessus a priori, faut bien gerer les conflits et qui a droit d’ecrire/lire ou a quel moment…
[quote name=‹ GloP › date=’ 28 Jan 2005, 21:17’]Cela dit c’est surement ce que le prof voulait les signaux et les semaphores et autres machins que tu as surement vu en cours
[right][post=« 326875 »]<{POST_SNAPBACK}>[/post][/right][/quote]
ah ah, m’entraîne pas sur la pente glissante des cours qu’on a eus, sinon j’y passe 10 pages…et pas en bien
Non, on n’a eu aucun cours de prog’ système ou même réseau en C (ou même dans un autre langage) cette année, juste un projet à faire. Heureusement pour moi que je m’en bouffe depuis qqes années maintenant, sinon je serais noyé (edit : mais je n’en avais pas fait depuis des mois maintenant…ça se perd vite ces trucs). Les autres se débrouillent avec une espèce de liste chaînée pas vraiment chaînée (compliqué à expliquer, en gros ils ont une structure avec le PID, l’état du process et un troisième champ contenant le PID du process’ « suivant ») et ils jouent avec les signaux.
Bref, typiquement un projet fait pour rajouter un truc sur le CV mais sans cours derrière (comme 90% des projets de cette année, au final). Quant au fait de dire que si c’est plus propre, c’est mieux, ben nan, faut vraiment respecter les consignes : si tu sors une bonne solution mais un poil HS par rapport à ce qui était demandé, tu te cognes un GROS malus (j’en ai fait les frais en début d’année). Donc exit les threads.
