Si les segments sont créés par un père, les fils héritent de son mapping automatiquement.
Euh non, ils héritent du même adressage virtuel (ie un pointeur vers une variable du pere aura la même valeur qu'un pointeur vers la copie de variable du fils)
Dans le cas de mémoire partager ils auront la même adresse virtuelle pour le même segment réel, mais pour les locks et compagnies il faudra quand même que le système fasse le map réel/virtuel pour chaque processus (en d'autres termes chaque lock engendrera un appel au mmu). Ce qui n'est pas le cas pour les threads.
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
a - moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
si tu veux passer par des messages intra processus pour signaler un lock c'est possible itou
b - si tu as besoin d'un vrai mutex bien agressif entre deux processus qui ne se connaissent pas forcéement (exemple : wrapper sur une ressource comme xfree ou driect fb) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 3.
Euh non, ils héritent du même adressage virtuel (ie un pointeur vers une variable du pere aura la même valeur qu'un pointeur vers la copie de variable du fils)
Dans le cas de mémoire partager ils auront la même adresse virtuelle pour le même segment réel, mais pour les locks et compagnies il faudra quand même que le système fasse le map réel/virtuel pour chaque processus (en d'autres termes chaque lock engendrera un appel au mmu). Ce qui n'est pas le cas pour les threads.
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
a - moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
si tu veux passer par des messages intra processus pour signaler un lock c'est possible itou
b - si tu as besoin d'un vrai mutex bien agressif entre deux processus qui ne se connaissent pas forcéement (exemple : wrapper sur une ressource comme xfree ou driect fb) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)