C'est toi qui a parlé de l'obligation d'utiliser de syscall pour synchroniser 2 process.
Tout à fait et je le maintiens
Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage
En user mode, même pas en rêve. Entre deux processus c'est le mur direct.
Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.
Pas du tout. Un pthread_spinlock a des inconvennients mais rien de comparable avec un spinlock de processus. Un pthread_spinlock n'est pas un while(1), c'est un event catcher. Ca n'a rien à voir ni en terme de charge ni en terme d'utilisabilité. Avec un pthread_spinlock tu as les retry, le test et le lock qui viennent de façon atomique. Rien que çà ca fait une ennorme différence.
Comme quelqu'un l'a suggéré un peu plus bas, il n'y a aucune différence au niveau OS entre la synchro de processus partageant de la memoire, et la synchro des threads
Le post de fin de thread pose un des résultats de notre discussion comme une évidence. J'ai donc préféré ne pas répondre.
C'est juste les bibliothèques en surcouche qui ont l'air différentes
Non, je t'assure qu'avoir un seul process au lieu de deux fait un différence réelle qui remonte jusqu'au hardware. ce n'est pas juste une illusion maintenue par du logiciel.
Synchorniser deux threads entre eux est un jeu d'enfant en utilisant readlock/writelock.
Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).
Alors dans le cas de processus en user space on en peut pas se contenter de boucler pour faire de l'attente active. Ca ne marche pas (on n'aura jamais un accès au segment atomique) il faut boucler + syscall (en d'autres termes faire un syscall immédiatement après la réalisation de la condition de test pour locker la ressource)
On peut par contre faire de l'attente passive en trhead sans jamais utiliser le moindre syscall grace aux signaux internes. Ca fonctionen comme un signal syscall, sauf que c'ets généré par le processus lui même à destination exclusive de ses trheads. Ca marche très bien.
[^] # Re: mmap ANONYMOUS n'a aucun surcout
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Tout à fait et je le maintiens
Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage
En user mode, même pas en rêve. Entre deux processus c'est le mur direct.
Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.
Pas du tout. Un pthread_spinlock a des inconvennients mais rien de comparable avec un spinlock de processus. Un pthread_spinlock n'est pas un while(1), c'est un event catcher. Ca n'a rien à voir ni en terme de charge ni en terme d'utilisabilité. Avec un pthread_spinlock tu as les retry, le test et le lock qui viennent de façon atomique. Rien que çà ca fait une ennorme différence.
Comme quelqu'un l'a suggéré un peu plus bas, il n'y a aucune différence au niveau OS entre la synchro de processus partageant de la memoire, et la synchro des threads
Le post de fin de thread pose un des résultats de notre discussion comme une évidence. J'ai donc préféré ne pas répondre.
C'est juste les bibliothèques en surcouche qui ont l'air différentes
Non, je t'assure qu'avoir un seul process au lieu de deux fait un différence réelle qui remonte jusqu'au hardware. ce n'est pas juste une illusion maintenue par du logiciel.
Synchorniser deux threads entre eux est un jeu d'enfant en utilisant readlock/writelock.
Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).
Alors dans le cas de processus en user space on en peut pas se contenter de boucler pour faire de l'attente active. Ca ne marche pas (on n'aura jamais un accès au segment atomique) il faut boucler + syscall (en d'autres termes faire un syscall immédiatement après la réalisation de la condition de test pour locker la ressource)
On peut par contre faire de l'attente passive en trhead sans jamais utiliser le moindre syscall grace aux signaux internes. Ca fonctionen comme un signal syscall, sauf que c'ets généré par le processus lui même à destination exclusive de ses trheads. Ca marche très bien.