Deja je crois que tu n'a pas compris que c'est dans la fonction malloc qu'il y a un mutex.
Mais ce mutex ne résoud absolument le probleme d'une thread qui libere par inadvertance une zone mémoire qui sera encore utilisée par une autre thread.
C'est pas un mutex mais un spinlock(grosse difference) et le probleme est le meme avec le multi-processus, un processus qui libere par inadvertance une zone utilisee par un autre processus ca tourne aussi a la catastrophe comme te je l'ai montre plus haut
Et pourquoi ? Toute sous-allocation doit se faire sans syscall. En utilisant exactement le meme code de sous-allocation dans un process ou dans une thread, on a exactement la meme performance.
La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque, donc tu dois te taper des mutex, qui sont 10x plus lents que les spinlocks --> perfs plus mauvaises.
Sans parler du probleme suivant :
Processus A cree un segment de memoire partagee a l'addresse 0x800A0000 pour y faire des allocations partagees et les passer au processus B
Processus B a une libraire chargee a l'addresse 0x800A0000, et donc ne peut pas mapper le segment a cette addresse.
--> Processus B ne peut pas utiliser directement les pointeurs sur le segment de memoire partagee passes par A, il doit decaler les pointeurs a l'endroit ou il a pu mapper le segment.
Je te le dis et redis, essaies toi meme et tu t'en rendras compte, c'est pas viable comme solution.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 1.
Mais ce mutex ne résoud absolument le probleme d'une thread qui libere par inadvertance une zone mémoire qui sera encore utilisée par une autre thread.
C'est pas un mutex mais un spinlock(grosse difference) et le probleme est le meme avec le multi-processus, un processus qui libere par inadvertance une zone utilisee par un autre processus ca tourne aussi a la catastrophe comme te je l'ai montre plus haut
Et pourquoi ? Toute sous-allocation doit se faire sans syscall. En utilisant exactement le meme code de sous-allocation dans un process ou dans une thread, on a exactement la meme performance.
La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque, donc tu dois te taper des mutex, qui sont 10x plus lents que les spinlocks --> perfs plus mauvaises.
Sans parler du probleme suivant :
Processus A cree un segment de memoire partagee a l'addresse 0x800A0000 pour y faire des allocations partagees et les passer au processus B
Processus B a une libraire chargee a l'addresse 0x800A0000, et donc ne peut pas mapper le segment a cette addresse.
--> Processus B ne peut pas utiliser directement les pointeurs sur le segment de memoire partagee passes par A, il doit decaler les pointeurs a l'endroit ou il a pu mapper le segment.
Je te le dis et redis, essaies toi meme et tu t'en rendras compte, c'est pas viable comme solution.