free2.org a écrit 2367 commentaires

Moi aussi j'arrete :)
Je te rappelle que l'article concerne la complexité du debuggage des threads.

Tu n'es vraiment pas objectif car tu n'as pas un dit un mot sur l'enfer de ce debuggage comparé au débuggage des processus multiples. Cet enfer des threads est bel et bien du aux fait que les variables privées ne sont pas respectées et que les threads encouragent à faire des algorithmes multipliant les variables partagées inutiles, et donc ajoutant de nombreux besoins de synchronisation supplémentaires qui ne sont pas toujours suffisament pris en compte.

Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.

Je retiens que le seul reproche à peu près valable que tu as fait à shm, c'est le fait que le malloc standard ne peut s'utiliser tel quel pour gérer les allocations dans un shm.

Si c'est le prix à payer pour avoir plus de fiabilité et de sécurité, je le paye sans problème.

CONCLUSION:
On peut très facilement utiliser shm pour remplacer un pipe ou une socket entre 2 processus. Pas besoin de malloc pour faire cela. Ce faisant, on obtient des performances similaires aux threads tout en utilisant la technologie éprouvée des processus qui est à la base de la fiabilité des UNIX.

La glibc 2.3 utilises des spinlocks pour locker malloc

Mais tu n'as pas besoin de spinlock dans le cas des varibales privées d'un process.
Et dans les cas des variables partagée tu as plein de biblios très simples.
Y'a pas plus simple qu'un spinlock, par définition.

vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
T'as entendu parler de X ? :)

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
Pas si il est sur de ne pas utiliser aucune des autres variables du segment, auquel cas il peut le détacher sans risque, meme si les autres process continueront à l'utiliser. Comme je l'ai deja montré plus haut :)

Quand je disais mutex, je voulais dire mutuelle exclusion. Pas la technique employée derrière pour rélaiser cette exclusion.

La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque
Attend, y'a pas plus simple qu'un spinlock.
http://en.wikipedia.org/wiki/Spinlock(...)
La encore plein de biblios libres sont disponibles.
Et de toutes façons un spinlock ça boucle donc c'est à éviter au maximum dans un algo.

Sans parler du probleme suivant :
On en a deja parlé. Soit le segment est hérité et tu as exactement la meme adresse que le pere, soit tu utilises des pointeurs relatifs ou des indices.

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.

Tout à fait, mais aucune sous allocation multiprocess ne peut aller aussi vite qu'une sous allocation multi-threads.
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.

Il n'y a pas de RMID pour mmap. Il n'y en a d'ailleurs pas besoin. La page table permet de savoir quels process ont le droit d'utiliser quelle page. Et au moment de swapper une zone inutilisée depuis longtemps, il est facile de vérifier si un process utilise encore cette zone. Si il n'y en a aucun, on peut alors libérer cette page sans l'écrire sur le disque.

Et je ne vois pas ce que les mutex viennent faire là dedans.

Merci. En effet c'est très intéressant pour faire des protections read-only valables pour toutes les threads (des constantes protégées par le système en quelque sorte).

Cependant mprotect n'est pas spécifique aux threads, et ne s'utilise qu'avec mmap (donc pas possible d'utiliser le meme malloc que d'habitude, mais ça c'est pas bien grave).
Cela veut dire que les protections concerneront tout le process et donc toutes ses threads auront exactement les memes droits au meme endroit.

Ce n'est donc pas utilisable pour dire que telle thread aura moins de droits que telle autre sur telle zone, contrairement à shm qui peut garantir qu'une variable privée est inaccessible aux autres.

Comme je l'ai dit ailleurs, mmap (MAP_SHARED|MAP_ANONYMOUS) produit aussi des segments partagés et n'a pas à mettre à jour une struct shm à chaque fork/attachement/detachement.

En effet, je parlais de nouvelles threads améliorées, donc non posix.

Oui bien sur, va allouer 25'000 shm, tu vas voir l'occupation en RAM apres..
Avec des pages standards de 4k:
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!

Dans le cas des threads, malloc est mauvais pour les performances et la sécurité/fiabilité:
1. Performances: consommation de CPU et de mémoire supplémentaire. Mutex obligatoire.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.

La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Or malloc impacte fortement les performances.
Beaucoup d'applications perfermantes sont obligées de gérer elle-meme leur allocations ou d'utilisent une bibliothèque d'allocation plus rapide (quitte à consommer un peu + de mémoire).

Et tu es de mauvaise fois sur les équivalents de malloc pour shm. Les bibliothèques d'allocation sont vieilles comme l'informatique et sont très bien éprouvées. Et encore une fois, les malloc standards peuvent fonctionner avec n'importe quelle zone mémoire sans le modifier: il suffit de les compiler avec un brk qui utilise shm au lieu d'utiliser le brk habituel.

Tu sais que POSIX est un standard à options.
L'option XSI fournit shmget, shmctl, etc
Et l'option realtime fournit shm_open, shm_unlik, etc

Tu peux consulter gratuitement les specs POSIX sur opengroup.org

allez un petit coup de malloc sur freshmeat:
http://freshmeat.net/search/?q=malloc&section=projects&Go.x(...)
retourne de suite un programme du domiane public:
http://freshmeat.net/projects/smalloc/(...)
Unlike malloc, however, smalloc takes a static memory buffer (as an initialization parameter). It is this buffer that smalloc manages when doling out memory to client code. This design makes smalloc ideal for use inside a Realtime Linux kernel module. It also makes it much easire to port userspace code that relies on malloc() in C or operator new() in C++ for memory management to a realtime kernel module.

J'ajoute qu'utiliser une bibliotheque à la malloc n'est utile que si les objets changent de taille. Si les process s'échangent des objets qui ont toujours la meme taille, cela ne sert à rien d'utiliser une bibilotheque. Les objets seront toujours alloués au meme endroit dans le segment à chaque itération.

Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
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.

Cas thread:
1) 5) et 6) sont pris en charge automatiquement par malloc/free, le soft lui-meme n'a qu'a faire 2) et 4) en utilisant malloc/free

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.
Par contre quand tu n'as plus besoin d'aucun objet dans le shm, tu peux toujours le détacher sans te préoccuper de savoir si d'autres process en auront besoin.
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 !

Pourquoi ? Parce que si ton soft partage des objets qui font 32 bytes, t'as pas envie de gaspiller une page entiere a chaque fois car ca devient une utilisation en RAM monstrueuse(sans parler du cout CPU de devoir ouvrire une shm pour chaque allocation).
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 !

Je reprend ici la discussion avec pbpg sur les bugs malloc, interrompue par la mise en page un peu plus haut:

Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free
Faux. Dans le cas des threads, avant de faire un free il faut s'assurer qu'aucune thread ne s'en servira plus jamais.
Dans le cas de shm, le process qui détache doit seulement s'assurer que lui ne s'en servira jamais.


(free reel dans le cas multithread, wrapper free dans le cas shm)
N'importe quoi. Free et malloc sont des bibliothèques C qui utilisent de temps en temps l'appel système brk pour faire varier la limite du tas de une ou plusieurs pages.
Shm est un appel système qui alloue (ou désalloue quand plus aucun process n'attache) exactement le nombre de pages dont on a besoin.

Mais en plus dans le cas shm tu dois suivre toutes les allocations pour savoir quand le segment complet peut etre detache, car pour les threads, la heap fait ca pour toi.
C'est carrément très discutable !
D'abord un process sans thread peut utiliser malloc comme il le veut pour ses variables privées. Et il a la garantie qu'aucun autre process ne viendra y accéder, contrairement aux threads qui peuvent mélanger leurs variables privées.

Pour les variables partagées shm, il faut juste faire attention à ne pas gaspiller le contenu des pages encore attachées (gaspillage qui ne peut pas se produire si on évite de créer et détruire plein de fois des petits objets partagés de tailles différentes, ce qui serait couteux en temps CPU). Quand on détache ces pages, on ne déclenche pas de bugs dans les autres proces, et elles seront libérées automatiquement quand tout le monde les aura détaché..
Si vraiment on tient à créer et détruire plein de fois des petits objets partagés dans le même segment shm (pourquoi ?) , on peut réutiliser la majeure partie du code LGPL de malloc dans la glibc.

Ces petits gaspillages facilement évitables sont beaucoup moins grave que le problème déjà évoqué pour les threads: libérer par free une zone mémoire peut entrainer des bugs siliencieux et donc très pervers.

Je te réponds plus bas, car là ça devient illisible.

les linux-kernel-headers contiennent les API offertes par le noyau Linux.
API= application programming interface
Ces fichiers sont nécessaires pour compiler des programmes utilisant ces API.

En français pour débutant ça donne: "fichiers décrivant la syntaxe à respecter pour être compris par le noyau quand on lui demande quelque-chose"

Tu peux utliser du code GPL en interne sans être obligé de le redistribuer.

Exemple concret: QT version GPL.
Si tu distribue le code source d'une appli utilisant les API QT, sans distribuer aucun fichier de QT avec. Tu ne violes pas la GPL.

Toutes les restrictions de la licence GPL sont dans sa section "redistribution du code original". Elles ne s'appliquent pas si tu ne redistribue pas le moindre bout du code original.

L'utilisation d'un programme GPL est libre, donc l'utilisateur aura final aura la liberté de compiler ton code source avec QT version GPL et de l'utiliser comme il le veut par la suite.

J'suis pas juriste.

Je crois que gdb est compatible est compatible avec nptl.
Mais il faudra peut-etre que les front-ends GUI soient mis à jour pour en profiter pleinement.

Comme l'article le suggère, stopper une thread ou l'exécuter pas à pas, cela peut changer la dynamique du programme et faire "disparaitre" certains bugs.

Cependant il est fort probable que ces bugs "disparaissant" sont dus à un manque de synchronisation systématique entre les threads, donc à un algorithme non fiable.

le probleme c'est que le process doit faire du resource tracking pour savoir quand il peut detacher le segment.
Ce n'est vraiment pas un problème spécifique à shm, au contraire !
Car cette obligation s'applique à toutes les zonnes mémoires allouées dynamiquement par tout process et tout thread. Et même dans le cas d'un processus monothread isolé. Il faut toujours s'assurer qu'aucun objet que l'on utilise ne se trouve dans une zone avant de la libérer par free !
Et si on ne veut pas se faire chier, il n'y a que la solution de la libération automatique à la mort du process (ou des process dans le cas de shm).

Avec les threads tu dois faire ce travail aussi. Et même encore + !

L'avantage de shm, c'est que un process n'a à se préoccuper que des objets qu'il compte utiliser par la suite. Pas des objets qui seront utilisés uniquement par les autres process pour des communications qui ne le concerneront pas.
Car en détachant un shm, un process ne supprime pas les objets alloués par les autres process pour leur propres communications.

Avec les threads tu dois aussi te préoccuper de tous les objets des autres threads, même si le thread actuel ne s'en servira jamais. C'est donc pire que avec shm !

Franchement, positionner le flag RMID dès la création d'un shm n'a rien d'une cuisine compliquée.
Sinon va voir ci-dessus la discussion sur mmap. On peut maintenant faire de la mémoire partagée entre process encore plus simplement.

Alors là c'est drole car tu viens de pointer une faiblesse supplémentaire des threads !
Non justement. Avec des threads tu fais des new ou des malloc, tu les liberes quand t'as fini et c'est tout
Pas du tout. Si une thread fais un free d'une zone qui est utilisée par une autre thread, c'est la cata (et il n'y a pas forcément de sigsegv, surtout si la zone était petite). N'oublie pas qu'elles sont dans le meme process et que free concerne tout ce process.

Par contre si un process détache un shm qui est attaché par un autre. Ce n'est pas la cata. Tant qu'un process attache ce segment, il continue à exister.

Ajoutons qu'un process peut aussi utiliser malloc pour sa mémoire privée. Ce que ne peuvent faire les threads.

Par contre, pour ceux qui veulent se faire facilement de la mémoire partagée héritable entre processus, mmap est en effet plus simple que shm. Et pour plaire aux pinailleurs, ça peut faire gagner quelques instructions lors des forks (pas besoin de mettre à jour nattch dans la struct shm).

Share this mapping with all other processes that map this object
Je suis enthousiaste pour cette utilisation de mmap avec les flags MAP_SHARED|MAP_ANONYMOUS !

C'est parceque la librairie Posix fait le tracking de ressources à ta place
Et c'est quoi le problème ? En quoi offrir une option RMID est-elle mauvaise ?

Il devrait y avoir exactement la même option de tracking dans les threads, sinon cette fonctionalité manque pour éviter systématiquement des fuites mémoires !

Ah ben oui, ca devient le bordel et il faut faire du resource tracking pour savoir quand le segment nouvellement alloue peut etre libere.
Mais il sera libéré de toutes façons dès que tous les processus l'utilisant seront morts !
Je crois que c'est ça que tu n'as pas compris.

Et si tu veux le libérer avant leur mort, alors il faut faire attention. Mais il y a exactement le meme problème avec les threads !

Tout ton raisonement n'est absolument pas valable pour un père qui utilise des shm, et les transmet automatiquement (après configuration optionelle) à chacun de ses fils.
Le système POSIX détache chaque fils automatiquement à sa mort, et le système POSIX libère automatiquement le shm à la mort de tous les process.
Aucune complexité, aucune source d'erreur.