Discussion :

[lagra3]

Bonjour à tous,

j'ai une toute petite question, je lis dans les bouquins qu'il fo travailler avec le module Thread de la sorte pour créer un nouvel Objet Thread: $t = Thread->new(\&fonc, $arg1, $arg2) (sans oublier bien sûr: use Thread; en tête de fichier).
Le seul problème est que ça ne marche pas dans le programme qui suit et pour que ça marche, il fo que je remplace Thread par threads: le voilà le programme:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
#!/usr/bin/perl -w
# prime-pthread, courtesy of Tom Christiansen
 
use strict;
 
use Thread;
use Thread::Queue;
 
my $stream = new Thread::Queue;
my $kid    = Thread->new(\&check_num, $stream, 2);
 
for my $i ( 3 .. 1000 ) {
  $stream->enqueue($i);
} 
 
$stream->enqueue(undef);
$kid->join;
 
sub check_num {
  my ($upstream, $cur_prime) = @_;
  my $kid;
  my $downstream = new Thread::Queue;
  while (my $num = $upstream->dequeue) {
    next unless $num % $cur_prime;
    if ($kid) {
      $downstream->enqueue($num);
    } else {
      print "Found prime $num\n";
      $kid = Thread->new(\&check_num, $downstream, $num);
    }
  } 
  $downstream->enqueue(undef) if $kid;
  $kid->join()         if $kid;
}

c'est juste un tout petit programme pour paralléliser le calcul des nombre premier allant de 3 à 1000.
Il est à noter que ça bloque juste avant de rentrer dans la boucle, chose que g vérifié avec des prints successifs dans le code.
Voilà voilà !!
Si vous avez la réponse merci de m'aider sur ce coup,
@+++,

lagra3

[Jedai]

Thread est le module des threads type 5.6, threads est le module des threads type 5.8, il faut utiliser threads et plus Thread. (et il vaut mieux carrément éviter les threads en Perl, plutôt utiliser des forks quand c'est raisonnable, et sinon des modules évènementiels type POE pour la plupart des autres cas)

--
Jedaï

[lagra3]

Thread est le module des threads type 5.6, threads est le module des threads type 5.8, il faut utiliser threads et plus Thread. (et il vaut mieux carrément éviter les threads en Perl, plutôt utiliser des forks quand c'est raisonnable, et sinon des modules évènementiels type POE pour la plupart des autres cas)

--
Jedaï

Merci Jedaï pour ta réponse.
Je suis tout à fait d'accord quand tu dis qu'il vaut mieux éviter de travailler avec les threads et utiliser plutôt fork dans la mesure du possible pour différentes considération à commencer par le fait que le modèle de thread est encore en phase d'expérimentation en Perl mais vois-tu je vois pas trop comment faire: par exple: pour le prog précédent je ne sais pas trop comment le traduire en un prog équivalent en travaillant avec fork car, pour commencer, fork impose une relation père-fils entre les processus et je n'ai pas le moyen d'attendre une réponse d'un processus que par le biais de son père (waitpid) ce qui est différent de ce qui est utilisé dans le prog en question (join) où on peut demander une réponse de la part d'un processus à partir de n'importe quel autre.
Si tu vois un moyen simple de traduire l'application précédente en une autre ne travaillant pas avec le modèle de thread mais simplement avec une duplication de processus en utilisant "fork" se serait cool que tu puisses m'aiguiller.
Merci et @+++,
lagra3.

[Jedai]

Qu'est-ce que tu racontes ? Ici join() ne sert absolument pas à récupérer un quelconque résultat, il joue exactement le même rôle que waitpid(). Dans cet algo l'intégralité de la communication se fait avec des Thread::Queue qui ressemblent beaucoup à des pipes...
Bien sûr les forks seraient sans doute moins efficients, mais vu que le but ici n'est pas l'efficacité :

En effet cet algo est un modèle d'élégance, mais n'a aucun intérêt réel : la taille des calculs effectués est telle que le gain serait sans doute nul même si tu disposais réellement d'une machine hyper-parallèle par rapport à un algo sans parallélisme. Eventuellement en découpant l'ensemble des premiers déjà trouvés en plus grosse parts, ça pourrait donner quelque chose.

(autrement dit quand je disais de favoriser les forks et les modules évènementiels, c'était dans le cadre d'applications du monde réel. NB : Si tu t'intéresse à l'informatique numérique et à la manipulation de donnée lourde en Perl, regarde plutôt du côté de PDL)
--
Jedaï