PERL - Communication processus pere/fils - Perl - Programmation
Marsh Posté le 13-12-2011 à 13:24:43
Vu que dans le modèle standard d'un fork, le processus fils ne partage pas l'environnement mémoire avec son processus père, mais en fait une copie, il n'y a aucune chance que les processus fils accèdent au tableau @tableau1.
Une solution à ce problème est décrite ici: http://docstore.mik.ua/orelly/perl [...] h16_13.htm
Bon, c'est pas portable dans tous les environnements, donc pas portable sous windows par exemple.
Citation : J’essaie de mettre en place un multi thread sur le code suivant. |
Il y a une raison particulière pour réinventer la roue, plutôt qu'utiliser une solution éprouvée comme Coro?
A+,
Marsh Posté le 13-12-2011 à 15:51:51
Bonjour,
Tout d'abord, merci pour cette réponse.
Ce que j'essaie de faire, c'est de mettre en place un script de démarrage de jobs de façon hiérarchisé.
Donc j'ai créé un code (cf ci-dessus) qui fait cela mais sans parallélisation. Maintenant que ce code fonctionne, j’essaie d'y implanter la parallélisation.
Mais étant un débutant en perl, il est fort possible que ma méthode ou que les bibliothèques utilisée ne soient pas les bonnes.
Pensez vous que coro puisse gérer un lancement hiérarchisé d'action en parallèle? En quoi est-il different de ForkManager?
En effet, dans sa description j'ai pu lire:
Citation : They are similar to kernel threads but don't (in general) run in parallel at the same time even on SMP machines |
Du coup, cela ne signifie t'il pas que la parallélisation ne fonctionne pas sur coro?
Merci,
Benjamin
Marsh Posté le 13-12-2011 à 16:17:35
Comme dit dans une doc, "Coro implements cooperative multitasking/multithreading with explicit task switching, while threads implements scheduled multitasking/multithreading. The advantage of Coro is that you don't get any race conditions. The advantage of threads is that you can get true parallelism across more than one CPU."
Mais si vous avez besoins de threads, pourquoi ne pas avoir utilisé ce qui existait déjà dans perl?
Bon en tout cas, si vous êtes sur une architecture de type unix, votre approche par des fork, plus l'utilisation de mêmoire partagée devrait suffire. Si vous êtes sous Win32, vaut mieux pas penser à cette approche, vu déjà que fork y est émulé par perl. Il doit y avoir moyen de faire ce que vous voulez, mais de manière OS dépendante avec les modules WIN32.
A+,
Marsh Posté le 14-12-2011 à 10:01:40
Bonjour,
Mon code doit être multi-platefrome car il doit tourner sur des UNIX et des Win32.
Donc pas de fork car ça doit pouvoir tourner sur du win32 et pas d'utilisation de "modules WIN32" car ça doit tourner sur de Unix.
Il me reste quelle option ?
Marsh Posté le 14-12-2011 à 11:49:24
De partir sur Coro et de laisser tomber le vrai parallélisme (ou de rester avec fork, mais de pas compter dessus sur une plateforme WIN32, ou de toute façon, IPC::Shareable n'a pas l'air d'être supporté), ou éventuellement essayer d'utiliser les threads Perl (mais comme j'ai jamais eu l'occasion de les utiliser dans mes programmes, je en sais s'ils implémentent un vrai parallélisme sous WIN32).
La le problème est pas limité à Perl: a moins de passer par des librairies spécialisées et multiplateformes ajoutant le support du vrai parallélisme la ou il est utile, le problème est assez général à tout code devant fonctionner sur des OS différents.
Il reste aussi la possibilité d'écrire du code OS dépendant avec un test sur l'architecture ($^O) pour décider de ce qui est appelé (un équivalent des ifdef du C) et en ce cas, la lecture de ceci: http://www.perlmonks.org/bare/?node_id=331029 n'est pas inutile pour la partie mémoire partagée et fork sous Windows (le bug est peut être corrigé depuis)
A+,
Marsh Posté le 16-12-2011 à 09:15:49
Re bonjour,
Après en avoir parlé avec les collègues, il s’avère que le code ne sera démarré que depuis des Red Hat.
En fait, la Red Hat va se contenter de lancer des ordres de façon parallélisé aux différents serveurs (unix, linux et win32).
Donc il me semble que al solution forkManager reste viable. (tant mieux, coro ne m'a pas semblé evidant a utilisé et je n'ai pas trouvé beaucoup d'exemples sur son utilisation).
Merci de m'avoir donné ton avis,
Cordialement,
Benjamin.
Marsh Posté le 13-12-2011 à 09:43:40
Bonjour,
La, je bloque vraiment.
Je fait un code qui utilise Parallel:ForkManager afin de pouvoir lancer des processus fils.
Ce que je voudrai, c'est que mes processus fils puissent modifier (en fait supprimer une case) un tableau qui est dans le main().
J'ai vu ces deux sujets:
ici et la
Mais je n'y comprend pas grand chose. Ces bibliothèques sont bien complexe.
Exemple de ce que je souhaiterai:
Si quelqu'un arrive a trouver une solution a ce probleme, je lui en serait vraiment reconnaissant.
(Sachant que je ne peux pas utiliser la communication par fichier car ce ne serait pas "suffisamment propre".)
Cordialement,
Benjamin
PS:
Si quelqu’un est curieux de savoir les raison de ces questions:
J’essaie de mettre en place un multi thread sur le code suivant.
Ce code simule un démarrage de Jobs de façon hiérarchisé.
Donc le code suivant fonctionne mais j'aimerai maintenant y appliquer du multi thread lors du démarrage des jobs (actuellement simulé par un "sleep rand 5;" )via la bibliothèque ForkManager.
Toutes les propositions sont les bienvenue, je sèche vraiment
Message édité par Super_carotte le 13-12-2011 à 09:46:33