Aide pour création de processus

[invite74b500b2]

Bonjours à tous !
Bon voilà ma question est dans le titre.
Je travail sur un programme sur linux dans le quel je dois créer plusieurs processus pour une même application (cahier des charges oblige).
Mon choix c'est naturellement orienté sur la librairie pthread.
Après quelques recherches, j'ai compris que lorsqu'on crée des tâches avec pthread_create(), elles sont toutes associées au même lwp (light-weight process) donc au même processus niveau kernel.
J'ai cru comprendre qu'en modifiant l'attribut de la tâche lors que sa création comme suit (pthread_attr_setscope(&attr,PT HREAD_SCOPE_SYSTEM) ), je serais en mesure d'indiquer que cette dernière soit assigner à un autre lwp que celui de la tâche qui la crée. corriger moi si je me trompe.
Et normalement mon probleme est résolu : j'aurais par exemple deux tâches qui sont dans deux lwp différents.
Vous allez certainement me conseiller la commande "fork()" Mais elle ne répond pas tellement à mes besoins mais bon si il n'y pas autre solution je plonge dessus.
-----

[invite74b500b2]

Je travail sur un programme sur linux.

A ouais, j'oubliais, je travail en c ou c++ à la rigueur !

[polo974]

Sauf erreur de mon interprète personnel (), sous linux, ça ne change rien...
un thread est une tâche qui partage le même espace mémoire (contrairement au process obtenu pat fork).
mais un thread sous linux a son numéro de process, comme tout autre process.

tu peux les voir en faisant un ps -efH (H pour tHread) ou un top -H.

Donc si tu as besoin de garder le même espace mémoire: thread,
si tu veux que le process père puisse mourir sans effet sur le fils, tu utilises fork.

[polo974]

un petit oups,
c'est top -H
mais ps -efL
...

[A voir en vidéo sur Futura]

[invite74b500b2]

ok merci ! Donc si je comprends bien, sur linux un thread est un process. Mais "bizarrement" lorsque j'essaie de lire le PID dans les différents thread j'obtient la même valeur.
Comment cela s'explique ?

[Jack]

ok merci ! Donc si je comprends bien, sur linux un thread est un process. Mais "bizarrement" lorsque j'essaie de lire le PID dans les différents thread j'obtient la même valeur.
Comment cela s'explique ?

c'est bizarre, parce que les pid sont effectivement différents. Il y a un processus pour le thread principal, un pour le manager thread qui va gérer tous les thread lancés et enfin un pour chaque thread.

A+

[invite74b500b2]

c'est bizarre, parce que les pid sont effectivement différents.

lol ! Salut, c'est pas si bizarre que ça : j'ai trouvé l'explication (je penses ) sur le man page linux

le terme « thread » est utilisé pour faire référence au processus d'un groupe de threads.
Les groupes de threads sont une fonctionnalité ajoutée dans Linux 2.1 pour gérer la notion POSIX de threads d'un ensemble de threads qui partagent un seul PID. De manière interne, ce PID partagé est ainsi appelé identifiant de groupe de threads (TGID) pour le groupe de thread. Depuis Linux 2.4, les appels à getpid(2) renvoient le TGID de l'appelant

Comme j'utilise Posix threads (pthread) ça explique donc pourquoi en faisant l'appel à getpid dans chaque thread j'obtiens le même résultat.
En faite c'est le PID (TGID) commun au groupe de thread au quel ils appartiennent.
Maintenant je ne sais pas comment faire en sorte qu'un thread ne soit pas dans le même groupe de threads que son prère.
Si quelqu'un à une idée, il est le bienvenu.
Sinon je planche sur l'appel système clone ()
a+

[Jack]

Pourtant, quand on lance une commande ps, on voit que tous les threads s'exécutent dans des processus différents.
Quand j'aurai un peu de temps je regarderai si la fonction getpid renvoit bien la même valeur.

Mais quel est ton problème exactement? Tu veux pouvoir identifier dans quel thread tu te trouves?

A+

[polo974]

Et si tu nous disais ce que tu veux comme résultat:
je tue le père, les fils meurent => thread
le fils partage le même espace mémoire => thread
je tue le père, le fils survit => fork
le fils a son espace mémoire séparé => fork

bon, c'est brut de fonderie, mais c'est l'idée...

l'appel à clone est une assez mauvaise idée, car il faut alors gérer des choses de très bas niveau que le C (eh oui, même le C) n'est pas sensé connaitre... (la direction de la pile)

de toute façon, c'est l'appel système utilisé par pthread

le père connait facilement l'identifiant de ses fils (lors du create).
un thread peut facilement connaitre son identifiant (pthread_self())
ensuite, les thread entre eux, ont le droit de causer, et en plus ils partagent le même espace mémoire...

[invite74b500b2]

Et si tu nous disais ce que tu veux comme résultat:
je tue le père, les fils meurent => thread
le fils partage le même espace mémoire => thread

le père connait facilement l'identifiant de ses fils (lors du create).
un thread peut facilement connaitre son identifiant (pthread_self())
ensuite, les thread entre eux, ont le droit de causer, et en plus ils partagent le même espace mémoire...

Mon but est de créer l'affinité processeur pour chaque thread.
Enfin bref c'est fait. La commande gettid() permet de lire l'identifiant du process du thread.
Je le préfère à pthread_self() qui renvoie quant à lui une donnée de type pthread_t utilisée localement pour la gestion.

Merci à tous

[invite74b500b2]

Salut tout le monde !
J'ai une question concernant l'exécution en parallèle !
Il me semble que lorsqu'on crée un programme multi-thread (avec pthread sous linux) les Threads s'exécutent en concurrent en non en parallèle.
Malgrés que le système soit multi-processeur, et les affinités processeurs définies séparément pour chaque thread et que l'attribut des threads soit positionné à "PTHREAD_SCOPE_SYSTEM".
J'aimerais avoir votre éclairage car il me semble que mes threads ne s'exécutent pas en parallèle (après vérification des sorties sur console chacun de me threads s'exécute et fini son exécution avant que les autres ne commence et ainsi de suite.)
Cordialement.

[polo974]

Si on regarde par là, on voit clairement qu'un programme multithead est exécuté sur tous les cores.
Bon, il faut aussi vérifier que l'os ne soit pas démarré avec l'option maxcpu=1 (cat /proc/cpuinfo donne les différents procs disponibles)

Et on peut utiliser la commande taskset (taskset - retrieve or set a process's CPU affinity).

sinon, la sortie sur les io (fichier et terminal) est vaguement asynchrone, il ne faut pas compter là-dessus pour connaitre l'ordre d'exécution. tu peux par contre dater à la nanoseconde tes messages pour ensuite faire le tri. tu peux aussi utiliser fflush(stdout) (ou le bon fd) pour accélérer la sortie sur le terminal (ou la trace), mais achtung, ça ralenti le reste...

[invite74b500b2]

Ok merci Polo974 !
Je m'en doutais !
Dis, mon système actuel pour tester mon programme n'a pas le support SMP. Est-ce que selon toi ça expliquerais mon probleme ?

[polo974]

Pas de SMP, Oui, ça explique, mais comme ça pour rire, c'est quoi ton système, car c'est géré depuis un bout de temps...

Il faudrait peut-être recompiler le noyau (si c'est très spécifique) ou en chargé un tout cuit plus récent...

[invite74b500b2]

Là j'utilise "debian-6.0.1" sur "virtualBox" avec virtualisation matériel me permettant d'augmenter le nombre de processeur à 2.
Bon, voilà j'ai lu quelque part (vite fais) qu'il y avait moyen de recompiler le noyau pour le support SMP. C'est l'origine de ma question précédente.

[polo974]

C'est donc un noyau moderne sur une archi PC, il est plus qu'improbable qu'elle ne soit pas nativement SMP.

Par contre, c'est au niveau des propriétés de ta machine virtuelle qu'il faut déclarer le nombre de coeurs que tu veux bien lui prêter.
dans la config de la machine cible (avant de la démarrer) système processeur, tu dois pouvoir affecter plus que 1 proc si ton hôte supporte la virtualisation et qu'il est multicore.

La prochaine fois, annonce la couleur dès le début quand tu bosse sur des machines virtuelles, car tu ajoutes des sources de pb qu'on ne peut pas deviner...

[invite74b500b2]

Par contre, c'est au niveau des propriétés de ta machine virtuelle qu'il faut déclarer le nombre de coeurs que tu veux bien lui prêter.
dans la config de la machine cible (avant de la démarrer) système processeur, tu dois pouvoir affecter plus que 1 proc si ton hôte supporte la virtualisation et qu'il est multicore.

.
Au faite, j'avais déjà changé la configuration de la machine virtuelle pour lui affecter deux processeurs(Bien avant de commencer).
Bon je vérifie encore et la configuration avec les 2 processeurs n'a pas changé
Là je suis largué...

[polo974]

Et les:
cat /proc/cpuinfo

il donnent quoi (sur les machines hôte et virtuelle)?

[invite74b500b2]

Et les:
cat /proc/cpuinfo

il donnent quoi (sur les machines hôte et virtuelle)?

Slt, Comme je ne maîtrise trop quoi mettre, je vais tout mettre
Voilà le résultat du cat /proc/cpuinfo (machine virtuelle)

$
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz
stepping : 10
cpu MHz : 2009.209
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht constant_tsc pni ssse3 bogomips : 4018.41
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Core(TM)2 Duo CPU T6570 @ 2.10GHz
stepping : 10
cpu MHz : 2009.209
cache size : 6144 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht constant_tsc pni ssse3 bogomips : 3932.20
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

$

La machine hôte est un Win7 (la commande ne marche pas).
J'ai essayé la commande "msconfig" pour mettre le nombre de cpu à 2.

[polo974]

argh, faire tourner un linux dans un windows...

Bon, il semble que tu dispose de 2 core dans ta machine virtuelle.

pour vérifier, tu prends un code bien lourd (http://shootout.alioth.debian.org/u3...&lang=gcc&id=4)
tu compiles
et tu fais un
time <prog param>
puis un
time taskset -c 1 <prog param>
normalement le second prend 2 fois plus de temps vu qu'il bloque l'exe sur le 1er core.
sinon, c'est louche...

[invite74b500b2]

argh, faire tourner un linux dans un windows...

J'y vais à mon rythme.

Sinon avec la "$uname --all" (je peux voir que le smp est bien effectif)
Bon Maintenant je vais analyser mes codes (séquentiels et parallèles) pour voir l'effet du parallélisme. Je crois que c'est la meilleure manière pour la vérification.
Merci pour l'aide pol974

[invite74b500b2]

Salut Polo974, j'ai encore une question à te poser. Et à tous les amis(es).
Comment mesurer le temps d'exécution globale d'un programme parallèle (par programmation).
L'idée est de comparer entre le même code s'exécutant soit en parallèle sur plusieurs processeurs ou soit en conçurent sur un seul processeur.
Merci d'avance.

[polo974]

message 20, il faut tout lire
voir taskset et time...

sinon, tu peux blinder et mettre maxcpu=1 sur la ligne de boot du kernel (dans grub) (ou dans la machine hôte ne prêter qu'un seul core).

[invite74b500b2]

message 20, il faut tout lire
voir taskset et time...

Ouais j'avais lu le post 20
Bon t'as pas bien compris ce que je voulais
Voilà les commandes taskset et time ça marchent bien, mais j'aimerais compter le temps nécessaire pour faire un traitement.
Par exemple j'initialise un compteur, puis je crée tous mes threads, et à la fin du traitement je lis combien de temps le programme à pris.
Enfin bref, j'ai essayé la fonction "clock()" mais bon ça résolution n'est pas si terrible.
A part ça j'ai essayé une panoplie de commande (clock_gettime() et même getrusage()) mais les resultats sont .
Donc si tu as une idée .
A part ça, j'ai pas trop compris les principes de temps Utilisateur et temps CPU (De toute façon le temps CPU n'est pas terrible sur un systeme SMP : Source ManPage Linux).

[polo974]

Euh, tu veux profiler ton code là thread par thread ...
C'est pas ma tasse de thé...

Il faut juste faire gaffe quand tu fais des opérations avec les ns et les secondes, car un débordement est vite arrivé (utiliser des unsigned long long pour être en 64 bits) !
(attention au code qui marche sur un 64 bit et plante sur un 32 bit)

un exemple de code:
http://www.guyrutenberg.com/2007/09/...clock_gettime/
mais j'essayerais aussi avec CLOCK_THREAD_CPUTIME_ID au lieu de CLOCK_THREAD_CPUTIME_ID

un truc à lire sur les machines virtuelles (vers la fin):
http://manpages.ubuntu.com/manpages/...TProf.3pm.html

et puis je viens de trouver:
http://www.ird.fr/informatique-scien..._profilage.php
(d'ailleurs dans le dossier guides, il y en a d'autres...)

[invite74b500b2]

Salut,
Les liens sont trop fort (je dois me mettre tout de suite à l'anglais lol). Même dans le deuxième lien ils déconseillent carément les marchines virtuelles.
Dis, tu penses quoi du "CLOCK_REALTIMEL" time pour mesurer le temps réel d'exécution ?
Bon voilà l'idée :
-Pour l'exécution parallèle: Au début je lis le temps dans une variable (au niveau du main), je fais l'affinité de mes threads pour qu'ils s'exécutent dans différents processeurs, puis je lance les threads qui normalement s'exécuteront en parrallèle dans les processeurs spécifiés. J'attends la fin de tous mes threads, puis je lis à nouveau temps et la différence me donne la durée réelle d'exécution. (la lecture du temps et le calcul de la durée ne se fera que dans le main).
-Deuxièmement (exécution séquentielle) : c'est pareil qu'au premier, mais cette fois-ci, j'associe tous mes threads par affinité processeur au même processeur (donc il s'exécuterons en séquentiel et non parallèle sur ce dernier). Puis je fais pareil (dans le main) pour le calcul du temps d'exécution.
Tu penses que ça peut donner quelque chose de significatif avec le "CLOCK_REALTIME" ?

[polo974]

Là, je vais te faire un aveux:
quand je commence à balancer plein de liens, c'est que je ne maitrise plus trop et que je découvre en même temps...
donc essaie de ton coté avec des truc triviaux, puis passe au plus compliqué...

et tiens nous informés...

[invite74b500b2]

ok, merci !
Je n'y manquerai pas

[invite74b500b2]

Je n'y manquerai pas

Slt, bref la suite a été longue mais finalement le travail est arrivé à terme.
Pour le "CLOCKREALTIME" il faut s'assurer que la version du noyau le prend en compte.
en ce qui concerne "CLOCK_THREAD_CPUTIME_ID" et "CLOCK_THREAD_CPUTIME_ID" cela dépend vraiment de ce qu'on veux mesurer. Bref en ce qui me concerne j'ai opter pour la commande "time".
a toute et merci pour l'aide ...

[JPL]

Merci d'avoir donné des nouvelles. C'est un geste trop rare.