Fedora-Fr - Communauté francophone Fedora - Linux

Communauté francophone des utilisateurs de la distribution Linux Fedora.

  

Dernière news : Fedora 37 Beta est disponible

#1 11/10/2011 21:47:18

Mongos
openAddict & pinguAddict
Lieu : IdF
Inscription : 25/06/2007
Messages : 879

[Résolu] À propos du fork

Bonjour à tous,

Afin de tester l'utilisation de la primitive fork, j'ai écris ce petit programme :

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>
#include <sys/time.h>

int main(void){
        struct timeval timestamp;

        if(fork()){
                /**** Père ****/
                int retour;
                gettimeofday(&timestamp,NULL);
                printf("Je suis le père, timestamp : %d.%d\n",(int)timestamp.tv_sec,(int)timestamp.tv_usec);
                wait(&retour);
                printf("Fils mort, code : %d\n",retour);
        }
        else{
                /**** Fils ****/
                gettimeofday(&timestamp,NULL);
                printf("Je suis le fils, timestamp : %d.%d\n",(int)timestamp.tv_sec,(int)timestamp.tv_usec);
                printf("suicide !\n");
                exit(1);
        }
        return 0;
}

D'après mon cours, juste après le fork, le fils devrait s'exécuter avant le père. Or lorsque je teste ce programme sur un noyau 2.6.35 ( de Fedora 14), j'ai le père qui s’exécute en premier...

Je suis le père, timestamp : 1318267786.474512
Je suis le fils, timestamp : 1318267786.474590
suicide !
Fils mort, code : 256

alors que sur un 2.6.18 (centos 5) on a bien le comportement escompté.

Je suis le fils, timestamp : 1318268002.606678
suicide !
Je suis le père, timestamp : 1318268002.606790
Fils mort, code : 256

Il y aurait-il eu un changement de politique dans le gestion du fork ? Quel en est la raison ?

Merci d'avance,

Mongos


Il n'y a pas de problème, juste des solutions

Hors ligne

#2 11/10/2011 22:05:12

WilQu
Membre
Lieu : Île-de-France
Inscription : 16/02/2008
Messages : 615

Re : [Résolu] À propos du fork

Tu es sûr de toi ? Après le fork, il y a deux processus, je ne vois pas comment tu pourrais avoir la garantie que l'un s'exécute avant l'autre.

Hors ligne

#3 11/10/2011 22:18:20

Mongos
openAddict & pinguAddict
Lieu : IdF
Inscription : 25/06/2007
Messages : 879

Re : [Résolu] À propos du fork

Sûr de moi, non. Je ne fais que citer mon cours qui dit que pour des raisons de performance, le fils serait exécuté en premier (copy on write). J'ai fait le tests sur plusieurs noyaux. Pour les noyaux 2.6.35+, toujours le père est exécuté en premier, pour les noyaux 2.6.18- c'est toujours le fils. Les résultats sont assez constants tout de même.


Il n'y a pas de problème, juste des solutions

Hors ligne

#4 11/10/2011 22:25:23

ben51
Attention derrière toi ! un canard !
Rédacteur Wiki
Lieu : Bordeaux
Inscription : 24/03/2008
Messages : 1 069

Re : [Résolu] À propos du fork

Pour moi c'est purent aléatoire.

Hors ligne

#5 11/10/2011 22:25:59

WilQu
Membre
Lieu : Île-de-France
Inscription : 16/02/2008
Messages : 615

Re : [Résolu] À propos du fork

En effet, les résultats sont constants chez moi aussi. C'est une bonne question à poser à ton prof big_smile Cela dit ça n'a pas d'importance pour celui qui utilise le fork.

Hors ligne

#6 11/10/2011 22:44:52

Mongos
openAddict & pinguAddict
Lieu : IdF
Inscription : 25/06/2007
Messages : 879

Re : [Résolu] À propos du fork

WilQu a écrit :

En effet, les résultats sont constants chez moi aussi. C'est une bonne question à poser à ton prof big_smile Cela dit ça n'a pas d'importance pour celui qui utilise le fork.

Malheureusement, il n'a pas pu me répondre ^^" Du coup je cherche la réponse !
Alors oui dans la plus part des cas, cela n'a pas d'importance. Mais, cela n'empêche ma volonté de comprendre le fonctionnement, ne serait-ce que par curiosité.


Il n'y a pas de problème, juste des solutions

Hors ligne

#7 11/10/2011 22:53:38

philippe_PMA
Membre
Inscription : 06/03/2006
Messages : 2 032

Re : [Résolu] À propos du fork

Désolé, mais ton cours dit une connerie.

D'une part sur le principe, ce n'est pas déterministe.
Suivant l'OS (*Linux, *BSD, *nix, Mach, etc...) ça peut l'un, l'autre, ou l'un ou l'autre ...

D'autre part, encore faudrait-il savoir si ta machine est mono ou multi-core.
Sur un mono core, ça pourrait être déterministe, mais sur un muti-core ... niet !


Gigabyte Z77-D3H+core i5 3550+8Go DDR3-12800 (1333MHz) / ASUS P5B+Quad core Q9550+CG ASUS X1950 PRO+8Go DDR2-5300 (667MHz).
Boitier Antec remote fusion black+ASUS P5Q-EM+core 2 duo 6600+Intel GMA X4500HD+2Go DDR2-5300 (667MHz).
ASUS EeePC 1005PE, CPU atom N450, 2Go SoDIMM DDR2-5300 (667MHz).

Hors ligne

#8 11/10/2011 23:13:26

Mongos
openAddict & pinguAddict
Lieu : IdF
Inscription : 25/06/2007
Messages : 879

Re : [Résolu] À propos du fork

philippe_PMA a écrit :

[....]
D'une part sur le principe, ce n'est pas déterministe.
Suivant l'OS (*Linux, *BSD, *nix, Mach, etc...) ça peut l'un, l'autre, ou l'un ou l'autre ...
[...]

Mon cours ne concerne que Linux, et les tests que j'ai fait n'ont été fait que sous Linux bien entendu.

philippe_PMA a écrit :

[....]
D'autre part, encore faudrait-il savoir si ta machine est mono ou multi-core.
Sur un mono core, ça pourrait être déterministe, mais sur un muti-core ... niet !

Effectivement, je ne me suis pas posé la question du multi-core. Mais (oui je suis chiant smile) ayant fait les tests sur mon portable (mono-core) (testé en 2.6.18, 2.6.35, 2.6.40), sur mon fixe (dual-core)(testé en 2.6.18, 2.6.35) et sur un serveur dual-core (2.6.18), les résultats restent constant....à moins que je n'ai vraiment pas de chance dans mes tests....cela ne semble pas avoir réellement d'influence (dans ce cas là en tout cas).

Dernière modification par Mongos (11/10/2011 23:32:01)


Il n'y a pas de problème, juste des solutions

Hors ligne

#9 12/10/2011 08:39:26

ben51
Attention derrière toi ! un canard !
Rédacteur Wiki
Lieu : Bordeaux
Inscription : 24/03/2008
Messages : 1 069

Re : [Résolu] À propos du fork

Tu a testé avec différente charge ?

Hors ligne

#10 12/10/2011 10:41:31

Toinou87
Membre
Inscription : 27/10/2008
Messages : 362

Re : [Résolu] À propos du fork

sinon juste pour info, le printf c'est pas atomic


The mustard indicates progress.

Hors ligne

#11 12/10/2011 10:43:57

Refuznik
Membre
Inscription : 31/01/2007
Messages : 8 089

Re : [Résolu] À propos du fork

Il n'y avait pas eu un changement pour une meilleure gestion de fork ?
Car dejà depuis le 2.6.32, la politique du child run first a été désactivé par défaut car elle n'apportait pas plus de gain vu l'évolution des CPU, le TLB (translation lookaside buffer) ayant un meilleur rendement en continuant l'exécution du processus père à la suite du fork() (edith pas de frok()).

Dernière modification par Refuznik (12/10/2011 10:48:51)

Hors ligne

#12 12/10/2011 16:46:51

philippe_PMA
Membre
Inscription : 06/03/2006
Messages : 2 032

Re : [Résolu] À propos du fork

ben51 a écrit :

Tu a testé avec différente charge ?

Bis.
si une interruption, une fin d'IO ou que sais-je nécessite d'être traité, ça va changer le déroulement de l'exécution ....


Gigabyte Z77-D3H+core i5 3550+8Go DDR3-12800 (1333MHz) / ASUS P5B+Quad core Q9550+CG ASUS X1950 PRO+8Go DDR2-5300 (667MHz).
Boitier Antec remote fusion black+ASUS P5Q-EM+core 2 duo 6600+Intel GMA X4500HD+2Go DDR2-5300 (667MHz).
ASUS EeePC 1005PE, CPU atom N450, 2Go SoDIMM DDR2-5300 (667MHz).

Hors ligne

#13 12/10/2011 17:53:58

Mongos
openAddict & pinguAddict
Lieu : IdF
Inscription : 25/06/2007
Messages : 879

Re : [Résolu] À propos du fork

ben51 a écrit :

Tu a testé avec différente charge ?

Oui absolument, on a une très forte tendance (de l'ordre de 95%) du fils en premier pour les 2.6.18 et du père en premier pour les 2.6.35+, quelque soit le processeur.

Toinou87 a écrit :

sinon juste pour info, le printf c'est pas atomic

D'où la présence du timeval qui sert de témoin.


Refuznik a écrit :

Il n'y avait pas eu un changement pour une meilleure gestion de fork ?
Car dejà depuis le 2.6.32, la politique du child run first a été désactivé par défaut car elle n'apportait pas plus de gain vu l'évolution des CPU, le TLB (translation lookaside buffer) ayant un meilleur rendement en continuant l'exécution du processus père à la suite du fork() (edith pas de frok()).

Merci, c'est justement ce que je voulais savoir smile Je pense que j'ai eu ma réponse donc,

Merci encore à tous pour votre aide !


Il n'y a pas de problème, juste des solutions

Hors ligne

#14 12/10/2011 18:44:23

Refuznik
Membre
Inscription : 31/01/2007
Messages : 8 089

Re : [Résolu] À propos du fork

Tiens j'ai retrouvé un article de patrick_g qui en parlait en 2009
http://linuxfr.org/news/nouvelle-versio … -linux#cfs

Mais rien ne t'empêche de le ré-activer si tu en as besoin, il suffit juste de le préciser.

Hors ligne

Pied de page des forums