Tu peux aussi allouer un shm par buffer, c'est toi qui choisit la taille de tes shm.
Et du coup on évite très simplement le bug silencieux des threads quand on les détache.
Donc NON, ce n'est pas le meme probleme qu'avec les threads.
Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres....
Rien ne t'empeche de modifier facilement le malloc de la glibc pour qu'il gere aussi les allocations dans les shm. Le tas, comme un shm, est constitué de pages contigues. On peut donc gérer les 2 avec exactement la meme bibliotheque.
Non c'est malheureusement pas aussi simple, tout simplement parce qu'il faut garder des locks sur certains elements dans la heap, et avec des processus separes, tu peux pas faire ca de la meme maniere(pas possible d'utiliser un spin lock normal par exemple, faut le modifier pour qu'il soit sur un segment de memoire partagee)
Si tu ne veux pas réutiliser le malloc glinc, il y a deja plein de bibliotheques de gestion d'espace qui sont disponibles (un garnd nombre sont dans le domaine public d'ailleurs). C'est pas un probleme informatique récent ni difficile à résoudre !
Ca oui, combien ont l'avantage d'etre aussi utilisees, debuggees et optimisees que la heap de la glibc ? Aucun
Mais si les informations que s'échangent les process sont petites, tu as probablement intéret à utiliser des pipes ou des sockets locales (qui n'ont pas besoin du protocole IP et sont donc très rapides).
Tu évites par la même beaucoup de bugs de synchronisation !
Et tes performances s'ecroulent alors, parce que transferer 25'000 objets par un pipe c'est 100x plus lent que passer un pointeur.
Je te le redits, essayes toi meme, ecrits un soft un tant soit-peu complexe avec cette methode et tu verras toi meme que cela devient vite bien plus complique que le systeme de threads.
Les process avec shared memory c'est connu depuis longtemps, il y a une bonne raison pour laquelle ils n'ont pas supplante la gestion en multithread, c'est tout simplement pas adapte.
[^] # Re: malloc bugs pour threads, voir plus haut
Posté par pasBill pasGates . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Et du coup on évite très simplement le bug silencieux des threads quand on les détache.
Donc NON, ce n'est pas le meme probleme qu'avec les threads.
Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres....
Rien ne t'empeche de modifier facilement le malloc de la glibc pour qu'il gere aussi les allocations dans les shm. Le tas, comme un shm, est constitué de pages contigues. On peut donc gérer les 2 avec exactement la meme bibliotheque.
Non c'est malheureusement pas aussi simple, tout simplement parce qu'il faut garder des locks sur certains elements dans la heap, et avec des processus separes, tu peux pas faire ca de la meme maniere(pas possible d'utiliser un spin lock normal par exemple, faut le modifier pour qu'il soit sur un segment de memoire partagee)
Si tu ne veux pas réutiliser le malloc glinc, il y a deja plein de bibliotheques de gestion d'espace qui sont disponibles (un garnd nombre sont dans le domaine public d'ailleurs). C'est pas un probleme informatique récent ni difficile à résoudre !
Ca oui, combien ont l'avantage d'etre aussi utilisees, debuggees et optimisees que la heap de la glibc ? Aucun
Mais si les informations que s'échangent les process sont petites, tu as probablement intéret à utiliser des pipes ou des sockets locales (qui n'ont pas besoin du protocole IP et sont donc très rapides).
Tu évites par la même beaucoup de bugs de synchronisation !
Et tes performances s'ecroulent alors, parce que transferer 25'000 objets par un pipe c'est 100x plus lent que passer un pointeur.
Je te le redits, essayes toi meme, ecrits un soft un tant soit-peu complexe avec cette methode et tu verras toi meme que cela devient vite bien plus complique que le systeme de threads.
Les process avec shared memory c'est connu depuis longtemps, il y a une bonne raison pour laquelle ils n'ont pas supplante la gestion en multithread, c'est tout simplement pas adapte.