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.
Là il faut que tu m'expliques quels sont ces locks que le sytème a à gérer quand un père a des shm et fait un fork !
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 de l'attente pasive, tu utilises forcément un syscall avec passage en kernelspace. Et donc tout ton argument d'économiser un syscall tombe.
) 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)
Je ne vois pas en quoi une thread pourrait faire de l'attente active qui ne soit pas possible avec shm. Ni en quoi une thread pourrait faire de l'attente passive sans passer par un syscall !
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Là il faut que tu m'expliques quels sont ces locks que le sytème a à gérer quand un père a des shm et fait un fork !
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 de l'attente pasive, tu utilises forcément un syscall avec passage en kernelspace. Et donc tout ton argument d'économiser un syscall tombe.
) 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)
Je ne vois pas en quoi une thread pourrait faire de l'attente active qui ne soit pas possible avec shm. Ni en quoi une thread pourrait faire de l'attente passive sans passer par un syscall !