L'implémentation commence a être bien testée, cependant la plupart des bugs rencontrés avec la NPTL se trouvent au niveau de l'application utilisateur. Ces problèmes sont très difficiles à détecter et à résoudre car ils peuvent dépendre de plusieurs facteurs comme la charge de la machine et le nombre de processeurs.
De plus l'utilisation de débogueurs entraîne la modification de la dynamique des applications, ce qui rend leur utilisation très difficile dans un contexte multi-threadé.
PTT (POSIX Thread Trace Toolkit pour la NPTL), publié sous licence LGPL, a pour but d'aider à résoudre ces problèmes et à faciliter l'analyse d'applications multi-threadées complexes.
Il fournit des outils qui permettent de tracer les évènements importants intervenant au niveau de la NPTL (entrée/sortie dans les routines, prise/relâchement de lock, ...) tout en ayant un impact faible.
C'est en quelque sorte l'équivalent de LTT (Linux Trace Toolkit) sauf qu'on se place au niveau de la NPTL au lieu du noyau.
Un de ses avantages est qu'aucune modification au niveau kernel n'est nécessaire et qu'il est même possible d'utiliser l'outil sans la moindre intervention du super-utilisateur, ni modification de l'application.
![[en]](../images/en.png)
PTT (674 hits)-
NPTL Tests and Trace (406 hits)
-
NPTL (wikipedia) (451 hits)
-
LTT (278 hits)
-
Pajé (281 hits)
> Lire la dépêche (174 commentaires, moyenne: 2,2).
Vous avez demandé le commentaire #562585.
vs POSIX shared memory
Je pense qu'utiliser des processus communiquant via des POSIX shm est aussi efficace que les threads, et élimine certains bugs difficiles à cerner (notamment quand un thread modifie par inadvertance, via un pointeur, les données privées d'un autre thread).
[^]Re: vs POSIX shared memory
La création des threads est (normalement) beaucoup plus rapide que des forks (qui dupliquent toutes les sections données), et puis la programmation IPC (semaphores, mémoire partagé, file des messages) c'est un peu à s'arracher les cheveux. Quand ton programme s'arrête anormalement tu dois gérer le fait que les ressources partagées existent encore (ipcs et ipcrm, beurk)
Si tu veux du parallèlisme avec une division nette (on ne partage rien) alors va pour le fork, mais si tu veux un partage totale des ressources alors les threads sont nettement plus pratiques (et les locks plus faciles à mettre en place que les sémaphores, à mon gout).
Généralement les applis qui demandent de la performance utilisent des threads (apache 2, MySQL...)
Voili, voilou pour mes 2 centimes
[^]Re: vs POSIX shared memory
La création des threads est (normalement) beaucoup plus rapide que des forks (qui dupliquent toutes les sections données),
Les systèmes modernes, dont Linux, utilisent le copy-on-write: les données ne sont dupliquées qui si elles sont modifiées.
Quand ton programme s'arrête anormalement tu dois gérer le fait que les ressources partagées existent encore (ipcs et ipcrm, beurk)
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
[^]Re: vs POSIX shared memory
Les systèmes modernes, dont Linux, utilisent le copy-on-write: les données ne sont dupliquées qui si elles sont modifiées.
Tu dupliques la page contenant la variable, c'est donc bien plus lent que les threads qui ne dupliquent rien (hormis le PC).
Tout programme doit vérifier lors de son lancement qu'il n'y a pas eu de crash précédemment, afin de remettre de l'ordre si besoin.
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
Je ne dis pas que le choix des threads est tout le temps supérieur au choix du fork. ca dépend entièrement du projet. <mavie> Pour ma part, j'avais fait un projet il y a 6 ans pour l'INRA (Linux+OpenGL+Qt+IPC), ça traine encore sur ma page ouebe :-). Si c'était à refaire maintenant ce serait threads + sockets et pas fork + IPC. Les threads c'est beaucoup plus souple à mon sens (dans le cadre de ce projet en tout cas)...</mavie>
A toi la balle :-)
[^]Re: vs POSIX shared memory
Tu dupliques la page contenant la variable, c'est donc bien plus lent que les threads qui ne dupliquent rien (hormis le PC).
Dans le cas d'un process qui fork tout de suite après sa création et qui met toutes les données partagées dans des shm, aucune donnée n'est inutilement dupliquée. En + on peut mettre les données partagées en read-only dans un shm à part, qui ne sera pas modifiable par les process lecteurs (et sans ralentir l'accès à ces données).
ce qu'il n'y pas besoin de faire avec les threads (en ce qui concernen la gestion du parallelisme).
De toutes façons un shm permet aussi un effacement automatique quand aucun process ne l'utilise.
Je suis d'accord que shm n'est pas facile, mais la sécurité et la fiabilité valent un effort. On peut simplifier en réutilisant du code ou des bibliothèques. Il y a même des bibliothèques shm pour perl et PHP...
[^]Re: vs POSIX shared memory
Selon mes vieux souvenirs de la programmation parallèle multi-processus, lorsque tu crées un processus fils il y a duplication du contexte. Ceci signifie entre autre que sont dupliqués le pointeur de pile, celui d'instruction, etc. Or, ce qui consomme vraiment à l'exécution d'un tel programme n'est pas la duplication proprement dit (même s'il y a un coût) mais le changement de contexte à chaque fois que l'ordonnanceur donne la main à un des processus. C'est la raison pour laquelle les threads (anciènnement appelés processus légers) sont plus performantes dans ce cadre là et donc soutiennent théoriquement mieux la montée en charge en threads/processus.
[^]Re: vs POSIX shared memory, X
Ceci signifie entre autre que sont dupliqués le pointeur de pile, celui d'instruction
Ceci est vrai aussi pour les threads, sinon elles ne pourraient exécuter des fonctions différentes en même temps.
mais le changement de contexte à chaque fois que l'ordonnanceur donne la main à un des processus.
Ce coût est à relativiser puisque de toutes façons il y a changement de contexte (userspace <-> kernelspace) chaque fois que le noyau intervient (scheduler, interruption, syscall...). De + le copy-on-write et les shm/mmap permettent à des processus apparentés d'avoir des contextes très semblables.
Parlons performances: un serveur X local serait évidemment ultra sensible aux problèmes de latence liés à des changements de contexte. Et un X local utilise shm.
[^]Re: vs POSIX shared memory, X
Je pense que le noyau Linux doit se mapper dans une partie de l'espace d'adressage de chaque processus, et ainsi eviter un gros changement de contexte (pas de flush du TLB) lors d'un simple appel systeme.
[^]Re: vs POSIX shared memory, X
Effectivement, c'est comme cela que ça se passe.
Sur i386, sur les 4 Go de l'espace virtuel, c'est réparti ainsi:
- 3 Go processus utilisateur
- 1 Go espace noyau
Les 1 Go de l'espace noyau (commençant à 0xC0000000) sont
systématiquement mappés dans tous les processus.
[^]Re: vs POSIX shared memory, X, nouvelles threads
Et donc les 3 gigas sont suffisants pour ne pas ralentir des process ayant des contextes quasi identiques (un père utilisant shm et ses fils).
En fait je suis prêt à faire l'éloge des threads le jour où elle permettront de faire ce qu'on peut faire aujourd'hui avec shm:
1. Dire que telle zone mémoire n'est pas accessible à telle thread. (variables privées d'autres threads). sigsegv envoyé auto par le hardware sinon
2. Dire que telle zone mémoire n'est accessible qu'en lecture à telle thread. Sigsegv auto sinon.
On aura alors une équivalence parfaite entre shm et les threads.
[^]Re: vs POSIX shared memory, X, nouvelles threads
Ce n'est pas des threads que tu veux alors. Ou du moins, pas des threads POSIX.
Rien dans la norme POSIX n'impose aux threads d'être gérés par le noyau. Ils peuvent très bien l'être par une bibliothèque en mode utilisateur (ou même un peu des deux : cf NGPT d'IBM il y a un ou deux ans). La protection mémoire étant gérée au niveau de l'OS, si les threads ne le sont pas, tu ne pourras pas avoir les fonctionnalités que tu demandes. Donc reste à shm si tu veux ça. Les threads POSIX permettent de partager toutes les ressources d'un processus par plusieurs flots d'exécution. Si tu ne veux pas de ce partage, n'utilise pas les threads.
[^]Re: vs POSIX shared memory, X, nouvelles threads
En effet, je parlais de nouvelles threads améliorées, donc non posix.
[^]Re: vs POSIX shared memory, X, nouvelles threads
J'ai lu ta discussion avec pasBill sur le sujet. Seulement, les threads
ça n'a pas le même usage, et ça ne répond pas au même besoin que
SHM. C'est 2 choses complètement différentes.
Un thread, c'est un fil d'exécution. Les threads à l'intérieur d'un
processus se partagent le même espace d'adressage (voir mon
post un peu plus bas sur le fonctionnement pour i386). Donc quand
on modifie l'espace d'adressage, c'est valable pour tous les threads.
Après je ne comprends pas bien la remarque sur le ralentissement
par rapport aux 3 Go. Tu peux expliciter ?
Au fait, juste une remarque par rapport aux SHM. Sur un système
Linux/Unix, tu as des limitations par rapport au nombre et à la taille
de segments SHM que tu peux créér.
Par exemple, sous Linux, maximum 4096 segments pour le
_système_. Tu vas me dire que sous Linux c'est tunable (ce qui est
vrai), mais c'est pas forcément le cas de tous les Unix.
[^]Re: vs POSIX shared memory, X, nouvelles threads
Par exemple, sous Linux, maximum 4096 segments pour le
_système_. Tu vas me dire que sous Linux c'est tunable (ce qui est
vrai), mais c'est pas forcément le cas de tous les Unix.
Euh... de toute façon la mmu x86 ne sait pas gérer plsu de 4096 segments partagés. Tu peux tuner autant que tu veux, tu n'iras pas loin.
Kha
root est un privilège, pas un droit !
[^]Re: vs POSIX shared memory, X, nouvelles threads
???? Ca n'a strictement rien à voir.
Le principe même du segment de mémoire partagée est de mapper
les mêmes adresses physiques dans des tables de pages
différentes (appartenant à des processus différents).
Les tables de pages, on peut en créer autant qu'on veut (dans la
limite de la RAM dispo, évidemment). Après, l'OS met ce qu'il veut
dans les tables de pages.
Après, ne pas confondre avec la segmentation (avec les registres
CS, DS, etc.) où un index est codé sur 13 bits (de mémoire), ce qui
fait 8192 segments possibles.
[^]Re: vs POSIX shared memory, X, nouvelles threads
Le principe même du segment de mémoire partagée est de mapper
les mêmes adresses physiques dans des tables de pages
différentes (appartenant à des processus différents).
Je ne susi pas sur que celà soit aussi simple que çà. Il me semble bien que la mmu s'en mèle dans le cadre des segments partagés. Il faudra que je vérifie dans mes bouquins ce soir...
Kha
root est un privilège, pas un droit !
[^]Re: vs POSIX shared memory
Dans le cas d'un process qui fork tout de suite après sa création et qui met toutes les données partagées dans des shm, aucune donnée n'est inutilement dupliquée. En + on peut mettre les données partagées en read-only dans un shm à part, qui ne sera pas modifiable par les process lecteurs (et sans ralentir l'accès à ces données).
Ca c'est la theorie, en pratique le faire est extremement complexe, exemple simple: tu partages des structures contenant des pointeurs.
Tu dois t'assurer que ces pointeurs pointent tous dans des segments de memoire partagee, bref il te faut te taper une couche supplementaire au niveau des allocations, operations sur pointeurs,... pour etre sur qu'elles sont prises au bonne endroit, sans parler du risque d'erreur qui causera un AV, voire un eventuel trou de securite selon les cas.
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ? Il faut savoir que le segment n'est plus utilise du tout, donc il faut suivre toutes les allocations et s'assurer que le segment est completement vide, etc... Sinon tu gardes tous tes segments sans jamais les releaser et bonjour le bordel.
Idem pour la synchro, si tu utilises des threads, tu peux te contenter de spin-locks qui n'entrainent pas de context-switch, alors qu'avec des processus differents, soit tu dois gerer l'allocation de ces spin-locks sur de la memoire partagee(et selon les implementations c'est pas gagne, cf. critical sections de Windows par exemple), soit c'est le mutex, qui est bien plus couteux.
Les processus qui utilisent des segments de memoire partagee c'est pratique dans certains cas mais c'est _tres tres_ loin de remplacer les threads.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
exemple simple: tu partages des structures contenant des pointeurs.
2 solutions:
1. Tu utilises des pointeurs relatifs à l'intérieur d'un gros segment.
2. Les segments partagés ont été créé dans un père: tout le monde a donc les exactement les memes adresses absolues pour toutes les zones mémoires partagées (et pour tout ce qui était alloué dans le père d'ailleurs).
De meme, la gestion des ressources est plus complexe, comment tu fais pour pouvoir liberer un segment de memoire partagee ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Allocation des spin-locks: voir les 2 solutions ci-dessus. On peut noter que avoir à boucler et consommer du CPU pour éviter un appel système qui lui ne consomme pas de cpu quand il bloque, c'est de toutes façons une situation qu'il vaut mieux éviter dans un algo.
Je suis d'accord pour dire que des outils supplémentaires sont à utiliser en + de l'API Posix, si on veut se simplifier shm.
Par contre je ne vois pas quels outils vont empecher efficacement une thread de lire ou modifier, via un mauvais pointeur, les données privées d'une autre thread.
Ni comment imposer efficacement à une thread que telle zone mémoire ne lui est accessible qu'en lecture.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
2 solutions:
1. Tu utilises des pointeurs relatifs à l'intérieur d'un gros segment.
2. Les segments partagés ont été créé dans un père: tout le monde a donc les exactement les memes adresses absolues pour toutes les zones mémoires partagées (et pour tout ce qui était alloué dans le père d'ailleurs).
1) est couteux et dangereux vu qu'a chaque dereferencement il faut faire une operation, qui consomme des cycles, et qui risque d'etre oubliee
2) Ca revient a tout partager si tu veux etre sur que tes pointeurs sont valides, ou est des lors l'interet par rapport aux threads ?
shmctl(...,IPC_RMID,..): le segment est supprimé auto dès que plus aucun process ne l'utilise.
Comment sais tu que plus aucun process ne l'utilise ? La est la question. Pour qu'un process sache que le segment n'est plus necessaire, il faut en gros que le process fasse du garbage collection a la main pour etre sur que tout ce qui etait dans le segment n'est plus utilise ou reference, et c'est lourd.
On peut noter que avoir à boucler et consommer du CPU pour éviter un appel système qui lui ne consomme pas de cpu quand il bloque, c'est de toutes façons une situation qu'il vaut mieux éviter dans un algo.
Ca depend tres fortement du cas. Exemple typique : tu proteges une section ou tu fais tres tres peu d'operations. Resultat: un spin-lock the coutera moins de cycles CPU qu'un context-switch lors de l'appel systeme, et t'evitera un flush du cache lors du context-switch.
Les critical sections de Windows sont un mix entre les 2, vu qu'elles vont spinner pendant un nombre determine de fois, et si elles n'obtiennent toujours pas le lock, utilisent un mutex plutot que continuer a consommer des cycles.
Par contre je ne vois pas quels outils vont empecher efficacement une thread de lire ou modifier, via un mauvais pointeur, les données privées d'une autre thread.
Ni comment imposer efficacement à une thread que telle zone mémoire ne lui est accessible qu'en lecture.
Quelle difference ?
Si ton processus essaye d'acceder a un pointeur alors qu'il ne devrait pas, c'est qu'il y a qqe chose de serieusement faux dans le soft, il vaut donc mieux l'arreter a ce moment la que le laisser tourner et faire n'importe quoi.
Que ce soit des threads ou des processus, je ne vois pas vraiment la difference, dans les 2 cas ca resulte en un crash, soit du thread, soit du processus, et en general ca compromet l'ensemble de l'application.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
'a chaque dereferencement
Comment sais tu que plus aucun process ne l'utilise ?
nattch, le nombre de process qui attachent un segemnt, est géré auto par le système POSIX. ce qui lui permet d'effacer auto un segment quand il n'est plus utilisé si tu en a fait la demande par RMID (car laisser un segment sans proc peut être voulu aussi, et c'est aussi possible si tu ne fais pas de RMID).
Utilises la commande ipcs pour lister tous les IPC de ton système POSIX (je suis pas sûr que win respecte bien POSIX à la lettre :) ).
Les spin-lock sont évidemment utilisables facilement sur les segments partagés.
Je te rappelle que un seul segment, effacé automatiquement par RMID quand il ne sert plus, peut contenir toutes les variables partagées. Celles qui sont privées ne sont pas dans le segment.
Que ce soit des threads ou des processus, je ne vois pas vraiment la difference,
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Ces bugs ne sont systématiquement évitables, et sans surcout, qu'avec shm.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
nattch, le nombre de process qui attachent un segemnt, est géré auto par le système POSIX. ce qui lui permet d'effacer auto un segment quand il n'est plus utilisé si tu en a fait la demande par RMID (car laisser un segment sans proc peut être voulu aussi, et c'est aussi possible si tu ne fais pas de RMID).
T'as pas compris le probleme :
Processus A fait des allocations dans le segment X
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Il ne peut pas a moins de faire du resource tracking, ce qui est couteux et ajoutes de la complexite au code.
C'est simple: un thread qui utilise par inadvertance une variable privée d'un autre thread ne fait pas crasher l'appli: c'est un bug silencieux et très pervers.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
Comment est-ce que le processus A peut savoir que toutes les allocations faites dans le segment X ont ete liberees ? (histoire de pouvoir liberer le segment sans tout faire planter)
Tu n'as pas compris nattch et RMID !
Un process peut détacher un segment, et ce segment sera automatiquement libéré quand tous les process l'auront détaché.
Lis la spec POSIX. Un process qui se termine détache automatiquement.
Oui c'est un bug silencieux et pervers, mais je suis pas sur que la complexite supplementaire du code causee par l'architecture segments de memoire partagee introduise moins de bugs que l'architecture avec des threads
Dans le cas d'un père qui est le seul à utiliser l'API shm avant de laisser faire l'algo par ses fils (qui n'ont donc pas à utiliser l'API shm), il n'y a aucune complexité.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
Tu n'as pas compris nattch et RMID !
Un process peut détacher un segment, et ce segment sera automatiquement libéré quand tous les process l'auront détaché.
Lis la spec POSIX. Un process qui se termine détache automatiquement.
Mais j'ai parfaitement compris ca, c'est pas ca le probleme !
Processus X cree un segment de memoire partagee A
Processus Y ouvre le segment A
Processus X alloue de la memoire dans A pour ses buffers et autres qu'il va partager avec Y.
Processus X, avant de detacher le segment, doit etre 100% sur que tous les buffers qu'il a alloue dans A ont ete liberes et ne seront plus utilises. Sinon il risque d'acceder a un pointeur dans un segment devenu invalide.
Bref, le processus est oblige de faire du resource tracking pour savoir quand il peut detacher le segment.
Tu peux aussi voir ca comme ca :
Tu alloues un buffer de 10Mo, et tu l'utilises pour faire des petites allocations toi-meme. Tu ne peux pas liberer le buffer de 10Mo avant d'etre sur que toutes tes petites allocations ont ete liberees, sinon ton soft risque de dereferencer un pointeur devenu illegal.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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.
Et tu vois pas de probleme dans cette architecture ?
Si t'as un segment de 64Ko partage par le pere, et soudainement un fils doit allouer 256Ko pour un buffer qu'il doit envoyer a un autre processus, comment cela se passe ?
Ah ben oui, ca devient le bordel et il faut faire du resource tracking pour savoir quand le segment nouvellement alloue peut etre libere.
Ces segments de memoire partagee ne sont _pas_ une solution de remplacement aux threads, ils ne sont simplement pas fait pour.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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 !
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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.
C'est parceque la librairie Posix fait le tracking de ressources à ta place. ca ne se fait pas automagiquement. Les infos du RMID sont mise à jour par la lib (et via des appels systèmes encore si ca peut m'éviter de faire un poste supplémentaire plus bas.)
Le fait que toi, developpeur tu n'ais pas à le faire ne veut pas dire que ça n'est pas fait.
Kha
root est un privilège, pas un droit !
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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 !
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
Et c'est quoi le problème ? En quoi offrir une option RMID est-elle mauvaise ?
Houlà, attention je n'ai pas dit que c'était mal, loin de là. Au contraire ca me fait une chouette épine hors du pied comparés aux callbacks en pagaille chez win32 (oui parceque moi et la MFC ca fait 4). J'utilise courament les RMID et j'en suis très content.
Seulement quand on soulève le capot il y a pleins de truc sen dessous quif otn les appels systèmes à ta place pour le tracking. C'ets tout ce que je dis.
Quand on est dan sun thread, même si dans le code on a l'impression que tel thread met un lock et que tel autre réserve la mémoire ce n'est pas tout à fait vrai, en fait pour le MMU c'est le processus qui fait le boulot en nommant les locks, les mutexs et autres pour signaler aux différents threads qui fait quoi. Mais ca n'a pas de cohérence au niveau système, et unthread peut parfaitement retirer le lock posé par un autre thread (même si ca n'est pas recommandé du tout). On perd en fiabilité et en protection, mais en gagne en vitesse et en isolation.
En ce qui concerne la libération de la mémoire allouée, on peut soit créer facilement un compteur de références (vu qu'on est dans le même process c'est pas dur de redéscendre l'info aux threads). Soit se la jouer sagouin et libérer les segments quand le process s'arrette (solution tout à fait acceptable dans pas mal de cas, malgré sont coté gruik). Faire un compteur de références sur de la mémoire partagée n'est pas évident (jette un oeuil sur l'implémentation de RMID). Et un segment partagé n'est pas facilement libérable même quand le dernier process qui l'utilise s'arrette (il aurait plutot tendance à survivre et à rester mappable un moment).
Kha
root est un privilège, pas un droit !
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
et n'a pas à mettre à jour une struct shm à chaque fork/attachement/detachement.
Si tu utilises RMID si. Ca se fait automatiquement, mais le compteur de référence doit être mis à jour.
Si tu fais des locks, unlocks, mutexs etc. après le attribution du segment il faut aussi mettre à jour RMID et passer par des appels systemes et/ou MMU pour mettre à jour l'état du segment.
Kha
root est un privilège, pas un droit !
[^]mmap n'a pas pas de RMID
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.
[^]Re: mmap n'a pas pas de RMID
Il n'y a pas de RMID pour mmap.
Si tu n'utilises que mmap sur un segment non.
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 c'est pour shooter le segment à vue quand tout le monde l'a détaché je ne vois pas trop l'intérret de déranger mmap.
Et je ne vois pas ce que les mutex viennent faire là dedans.
Au sens large (mutual exclusion). Peut importe que ce soit en fait un marqueur file system géré par le kernel, ou une gestion mmu pure pour les locks des process ou autre. De toute façon au moindre changement il faudra que tous les process fassent un syscall pour connaitre l'état du segment avant de faire quoique ce soit d'un peu cavalier dedans.
Kha
root est un privilège, pas un droit !
[^]Re: mmap n'a pas pas de RMID
Si tu n'utilises que mmap sur un segment non.
Il n'y a pas non plus de RMID si utilise mmap dsur plusieurs segments. RMID est une api spécifique à shm.
Si c'est pour shooter le segment à vue quand tout le monde l'a détaché je ne vois pas trop l'intérret de déranger mmap.
??? je parlais du travail de gestion de la VM effectué par l'OS, pour toutes les pages, pas seulement celles issues de mmap, qui n'y changent rien.
De toute façon au moindre changement il faudra que tous les process fassent un syscall pour connaitre l'état du segment avant de faire quoique ce soit d'un peu cavalier dedans.
Prenons le cas d'un segment qui sert de buffer d'échange permanent entre 2 process (une sorte de pipe instantané): le syscall_sémaphore est remplaçable par un spinlock stocké en début de shm.
[^]Re: mmap n'a pas pas de RMID
Il n'y a pas non plus de RMID si utilise mmap dsur plusieurs segments. RMID est une api spécifique à shm.
Je pensais surtout au mappage d'un segment déjà partagé ailleurs via shm.
??? je parlais du travail de gestion de la VM effectué par l'OS, pour toutes les pages, pas seulement celles issues de mmap, qui n'y changent rien.
Dans les pages mmaper, tu as un fs qui tient le segment occupé même si tous les process qui l'attachent crashent ou se ferment les uns après les autres. Ca permet d'avoir une info qui est dépendante d'un fs au lieu d'être liée à des processus. C'est très pratique pour garder une info "sous le coude". mais si tu n'as pas besoin de cette fonctionalité, autant utiliser shm et des call-back pour faire le boulot.
Prenons le cas d'un segment qui sert de buffer d'échange permanent entre 2 process (une sorte de pipe instantané): le syscall_sémaphore est remplaçable par un spinlock stocké en début de shm.
META GNI ???
Pris un à un je comprend les mots de ta phrase, mais ensembles j'ai du mal à saisir. Les spinlocks c'est pour les threads ou quand tu es absolument sur que toutes opérations sur ton segment seront atomique, et faire un lock sur un segment mémoire partagé entre deux processus sans passer par des appels systèmes, je vois pas comment on peut faire.
Qaund à placer le spinlock en début de shm, ca veut dire qu'il y a un while(1) ou équivalent qui tourne en boucle en permanence dans uns des deux process ? Déjà bonjour le CPU et ensuite j'imagine que quand tu reçois uen info tu break ton while pour sortir (vu que tu n'aimes pas les threads je vois pas comment faire autrement). Là tu fais ton petit traitement et tu relances le while j'imagine. Et tu fais comment pour savoir si il y a eu mise à jour ou pas ? Si tu as loupé des données ? Si c'est pas l'info déjà lue la seconde d'avant ?
Tu es obligé de mettre en place tout un protocole non ? Et de faire des tests. mais si tu fais des tests, tes accès au segment ne sont plus atomiques et donc tu n'es pas sur que le segment que tu as testé est le même que celui que tu vas lire....
Bref tu vas te prendre de ses retours de manivelle quelquechose de violent et ua niveau synchro tu vas pas aller loin. La seule façon de coordoner tes actiosn entre les deux threads c'est de passer par des syscall pour prevenir l'autre thread de ce qui se passe.
Une solution possible, mais pas forcément ecconome consiste à passer par des callbacks. Mais là aussi bonjour l'archi à mettre en place.
Kha
root est un privilège, pas un droit !
[^]mmap ANONYMOUS n'a aucun surcout
Je pensais surtout au mappage d'un segment déjà partagé ailleurs via shm
mmap MAP_SHARED|MAP_ANONYMOUS a deja été évoqué pour partager de la mémoire entre un père et sa descendance: aucun syscall de type shmget, aucun fichier ou filesystem lié, pas de RMID/nattch: bref aucun surcout en utilisant cette méthode mmap ANONYMOUS.
C'est toi qui a parlé de l'obligation d'utiliser de syscall pour synchroniser 2 process.
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 effet. Les spinlocks ont des inconvénients, et je ne les aime pas plus que toi. Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.
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. C'est juste les bibliothèques en surcouche qui ont l'air différentes. Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).
[^]Re: mmap ANONYMOUS n'a aucun surcout
Ça fait un bout de temps que je vous regarde vous étriper sur les mutex/spinlock.
Quelques remarques :
1) Conceptuellement, mutex et spinlock, c'est très semblable. Les spinlock peuvent être vus comme une implémentation particulière de mutex à base d'attente active. Si le processeur possède des instructions atomiques, il est possible d'implémenter les spinlock entièrement en espace utilisateur. Seul pb: risque d'occupation indue du processeur. Risque de deadlock également si les priorités 'hard' des deux flots d'exécution sont différentes.
2) Pour synchroniser des flots d'exécution parallèle (j'entends par là "gérés par l'ordonnanceur du noyau"), l'arbitrage du l'ordonnanceur du noyau est indispensable pour éviter le problème évoqué précédemment (attente active, risque de consommation du CPU pour rien, deadlock, ...)
3) Depuis les noyaux 2.6 (peut-être pas les premiers), Linux contient les 'futex'. Ils permettent de synchroniser des flots d'exécution parallèle en restant en espace utilisateur s'il n'y a pas de contention et en demandant l'arbitrage du noyau dans le cas contraire. A noter que ce mécanisme ne suppose pas que les flots partagent la même VM. La nouvelle libpthread (nptl) permet ainsi de faire de la synchro entre threads d'applications différentes grâce à des futex placés dans une zone de mémoire partagé (cf pthread_mutexattr_setpshared())
Enfin, une remarque générale. Les problèmes de synchro sont globalement les mêmes entre threads ou process avec mémoire partagée. L'intérêt des threads étant qu'il y a déjà beaucoup d'outils dispo (mutex, sémaphores, ...) qui utilisent les futex (crucial pour avoir de bonnes perf dans un maximum de cas).
Avec les process à mémoire partagée, il faudra réécrire ces outils (c'est peut-être déjà fait, mais je ne connais pas). En outre, le code de démarrage/arrêt est plus compliqué : il faut gérer des 'objets' extérieurs au processus, donc l'initialisation et la destruction à la terminaison est plus délicate. Pour les threads, l'initialisation se déroule naturellement au démarrage lorsque les threads ne sont pas encore créés, et la destruction est faite par l'OS à la destruction du processus.
Et pour finir, ne pas oublier qu'avec la mémoire partagée, rien ne certifie a priori qu'elle sera mappée au même endroit : cela oblige à manipuler des handle plutôt que des pointeurs, ce qui peut être source d'une indirection supplémentaire (et de complexification du code et des structures de données)
[^]Re: mmap ANONYMOUS n'a aucun surcout
La nouvelle libpthread (nptl) permet ainsi de faire de la synchro entre threads d'applications différentes grâce à des futex placés dans une zone de mémoire partagé (cf pthread_mutexattr_setpshared())
Donc rien n'empeche 2 processus communiquant par shm de se servir de la libpthread pour se synchroniser par futex !
[^]Re: mmap ANONYMOUS n'a aucun surcout
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.
Kha
root est un privilège, pas un droit !
[^]Re: mmap ANONYMOUS n'a aucun surcout
J'aimerais bien savoir techniquement, comment un thread peut-il faire de l'attente passive (pas de consommation CPU, il n'est donc plus shédulé du tout par le système) sans faire un appel système pour dire: je rend la main tant qu'il y a ce lock, schédulez quelqu'un d'autres à ma place.
Ou sinon tu utilises un scheduler coopératif customisé à l'intérieur de ton process, avec consommation de CPU supplémentaire pour gérer ce scheduling interne.
[^]Re: mmap ANONYMOUS n'a aucun surcout
Ou sinon tu utilises un scheduler coopératif customisé à l'intérieur de ton process, avec consommation de CPU supplémentaire pour gérer ce scheduling interne.
Si on considére que les scheduling scope/domain des pthreads sont un scheduling coopératif customisé, alors oui je customise à fond. Et oui j'ai une sous attribution de time slice qui doit bien consomer une douzaine de cycles CPU en overhead pour prendre la main, redistribuer aux threads, récupérer la main et la rendre.
La lib pthread fourni un excellent scheduler interne et j'avoue m'en servir.
Kha
root est un privilège, pas un droit !
[^]scheduling intra process, voir plus bas
je te réponds plus bas
[^]Re: scheduling intra process, voir plus bas
je te réponds plus bas
Je dois être mauvais en jeux de piste, j'ai pas trouvé de post postérieur à 23:36...
Kha
root est un privilège, pas un droit !
[^]Re: scheduling intra process, voir plus bas
ça y'est... j'avais pas encore fini de taper :)
[^]scheduler intra-processus, voir plus haut, sécurité/rapidité
Je répond ici à Kha sur le scheduler interne:
Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données. Dans le cas de nombreux algorithmes où des processus s'échangent de gros blocs par pipe ou socket, le principal gaspillage est la recopie de ces blocs, évitable par shm.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv, je pense qu'il y a plusieurs niveaux de compromis entre la sécurité et les performances:
1. Pour la plupart des programmes d'un Unix qui passent l'essentiel du temps à dormir, il n'y a clairement pas besoin de s'embetter avec des threads. Ni avec les shm.
2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.
3. Quand on veut des bêtes de course fiables (genre les serveurs web Zeus, ou thttpd/mathopd en libre) on peut éventuellement avoir recours à quelques taches ou quelques process (en nombre suffisant pour faire travailler tous les procs d'un SMP), mais surtout à select pour éviter des taches/process inutiles.
La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.
Ou, si on est prêt à se casser la tête pour démontrer l'absence de tout overflow dans un programme concurent (bonne chance), faire du multithread masssif. Avoir des variables read-only protégées par mprotect peut aider un peu dans ce cas.
4. Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.
[^]Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Le plus long est de poser des masques sur les threads pour els signaux. Mais après le role de ce scheduler est très réduit.
Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données.
Ou quand on veut une bonne maitrise de la synchro, ou quand on veut un déroulement "dans l'ordre" de certaines fonctions (en temps réel par exemple), ou quand on veut prioritiser dynamiquement un thread par rapport à l'autre sans nicer tout le processus ou quand veut effectuer un maximum de changement entre deux threads dans le time-slice etc.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv,
Dans les threads c'est vrai qu'il n'y a pas de variables vraiment pivée, mais si tu protèges une zone mémoire autant que tu le peux, le thread qui passe au travers ne peut pas vraiment prétendre ne pas l'avoir fait exprès (on n'outrepasse pas un writelock par débordement de tableau).
2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.
Tout à fait, les meccanismes de callback peuvent aussi aider grandement.
La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.
La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux. C'était le système de référence dans Unix devant les sockets et les pipes. On peut parfaitement définir des masques d'interceptions qui assurent que tel signal sera toujours traité par tel thread.
Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.
Gérer des threads peut être très simple sur des taches concurentes parallèles, ne serait-ce que parceque je peux régler l'ordre de déroulement de mes threads sans faire de tests via le scheduler PThread. Tache ardue, si ce n'est impossible avec le scheduler standard.
Les threads permettent également de découper le traitement en petits traitements simples de façon très simple, alors que faire la même chose en SHM demande souvent de créer des protocoles de dialogues inter-processus complexes.
Kha
root est un privilège, pas un droit !
[^]Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux.
Les signaux sont des interruptions, pas un échange de donnée. Tu fais comment pour échanger des données sans recopie entre 2 entités ayant des privilèges différents , avec un signal ?
[^]Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Les signaux sont des interruptions, pas un échange de donnée. Tu fais comment pour échanger des données sans recopie entre 2 entités ayant des privilèges différents , avec un signal ?
On peut, mais c'est très con. Ceci étant je croyais que le but était de séparer les privilèges, dans ce cas là ca marche très bien.
Kha
root est un privilège, pas un droit !
[^]séparation des privilèges
On peut [échanger des données sans recopie, entre 2 entités avec des privilèges différents, avec un signal], mais c'est très con.
Peut-on avoir une indication pour éclairer notre lanterne ?
Ceci étant je croyais que le but était de séparer les privilèges, dans ce cas là ca marche très bien.
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
[^]Re: séparation des privilèges
Peut-on avoir une indication pour éclairer notre lanterne ?
Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Là aussi, peux-tu expliquer comment 2 threads d'un meme process peuvent séparer leur privilèges ?
En théorie ils ne peuvent pas, en pratique c'est pas grave.
Méthode du gros rouge qui tache.
le thread t1 veut une variable privée A
il pose un write-lock dessus
il pose une variable de condition signal sur la présence write-lock
Au cas ou il recoit un signal sur cette condition, ils ait qu'un autre thread a enlevé le write-lock pour aller écrire dans la variable. De rage il termine le processus.
Méthode plus subtile, mais à peine :
Le scheduler a une variable en readlock qui contient le dernier thread appelé
le thread veut une variable privée B
il créé deux variables B1 et B2
il write-lock les deux variables
il les mets à la même valeur
il pose 3 variables de condition signal : 2 sur la présence de chacun des writelock et un sur l'égalité de B1 et B2
Au cas ou il recoit un signal sur une des trois conditions
a) detach du dernier thread appelé
b) constatation des dégats : peut-on dire qu'une des copies est fiables ? (généralement : oui)
c) réparation des dégats : on reduplique la copie fiable et on remet les locks.Si la réparation est impossible exit.
Le gros problème c'est que c'ets lourd, lent et qu'il y a des pièges de synchros et des conditions de courses dans tous les sens. Je laisserais pas çà dans un code en prod, mais pour le débug ca marche pas mal du tout. En y passant du temps il doit être possible de faire une implémentation "propre" sur la même idée (ie un truc dans lequel on est sur à 100% qu'un thread n'a pas pu enlever les deux write-lock, changer les valeurs des deux variables et remettre les deux write-lock à l'identique sans que les variables de conditions n'aient le temps d'être mise à jour.)
Kha
root est un privilège, pas un droit !
[^]Re: séparation des privilèges
>On peut [échanger des données sans recopie, entre 2 entités avec des privilèges différents, avec un signal], mais c'est très con.
>>Peut-on avoir une indication pour éclairer notre lanterne ?
>Tu as déjà joué au ping-pong ?
Ben la même chose avec deux porcess qui se lancent des alarmes (j'avais dit que c'était très con)
Et tu appelles ça un échange de données sans recopie par le noyau ? Euh...
On a pas la même définition de privilèges. Je parlais de l'uid (user id) et du gid (group id) associé à un process.
Pour toutes les taches d'un meme process pid et gid sont évidemment identiques.
Ce qui veut dire que si une tache a une faille de sécurité, les autres sont compromises aussi. Ainsi que toutes les ressources du système auquelles les autres sont censé avoir accès via leur uid/gid.
Quand des process communiquent par shm, chacun peut avoir ses propres uid et gid.
[^]Re: séparation des privilèges
On a pas la même définition de privilèges. Je parlais de l'uid (user id) et du gid (group id) associé à un process.
Pour toutes les taches d'un meme process pid et gid sont évidemment identiques.
Ce qui veut dire que si une tache a une faille de sécurité, les autres sont compromises aussi. Ainsi que toutes les ressources du système auquelles les autres sont censé avoir accès via leur uid/gid.
Euh.... Tu laggues ?
Tous les threads d'un process ont le même uid et le même gid si tu veux, mais c'est pas pour autant qu'on ne peut pas les protéger les uns des autres. La protection uid/gid est une spécificité Linux. La mmu s'en balance, la seule chose qu'elle connaisse c'est pid. Tout le reste c'est logiciel. Et niveau logiciel on a fait de très gros progrès que ce soit dans le monde Linux ou dans le monde Windows. SE-Linux permet par exemple de définir des domaines, très pratique pour la séparation des taches. On se loggue en root, mais dans un domaine particulier et on a les droits root que sur un sous ensemble du système (éventuellement nul).
La bonne nouvelle c'est qu'on peut enregistrer deux threads d'un même process dans deux domaines différents. Je crois (PBPG confirmera ou infirmera) que l'on peut faire le même genre de chose avec Windows 2003.
La dessus je vais pas pouvoir m'étendre, je sais que c'est possible mais je n'ai pas encore jeté un oeuil approfondi sur les implémentations.
Kha
root est un privilège, pas un droit !
[^]Séparation des privilèges impossible avec threads actuelles !
La bonne nouvelle c'est qu'on peut enregistrer deux threads d'un même process dans deux domaines différents.
Je ne sais pas si tu réalises à a quelle point cette protection serait foireuse !
Prenons le cas d'une thread T1 qui n'a pas accès à la ressource R à laquelle accède la thread T2 du même process. T1 n'a qu'à modifier la mémoire utilisée par T2 pour pouvoir accéder indirectement à R.
C'est catastrophique au niveau sécurité.
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Je sais pas si tu réalises à quel point tu racontes n'importe quoi sur des choses desquelles tu n'as visiblement aucune connaissance pratique. Je ne parle pas seulement de ce dernier point, mais de l'ensemble de la discussion.
Mais alors là, je craque total. Ose seulement répondre que tu as regardé comment fonctionne SELinux (ou l'équialent Windows que je ne connais pas) avant de poster ton commentaire débile...
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Restons calme et poli, surtout quand on ne donne pas d'argument précis pour se justifier.
Puisque tu as parfaitement compris comment fonctionne SELinux (gestion de droits d'accès supplémentaires au moment de chaque syscall), tu vas m'expliquer comment SELinux peut détecter lors d'une slice se déroulant en userspace, que la thread T1 a modifié des variables privées de la thread T2 afin de lui faire faire des choses non voulues avec la ressource R.
Répond avec une argumentation précise, pas une insulte.
[^]Re: Séparation des privilèges impossible avec threads actuelles !
tu vas m'expliquer comment SELinux peut détecter lors d'une slice se déroulant en userspace, que la thread T1 a modifié des variables privées de la thread T2 afin de lui faire faire des choses non voulues avec la ressource R.
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Par contre si on s'autorise les appels systèmes, un mutex (au sens système du terme, par un lock informatif pthread) posé par un thread d'un domaine peut parfaitement devenir totalement insensible au niveau kernel à une demande de retrait par les threads des autres domaines.
Par contre dans ce cas là impossible de faire sauter le syscall.
Kha
root est un privilège, pas un droit !
[^]Re: Séparation des privilèges impossible avec threads actuelles !
C'est sur que si tu veux des variables privées ET une protection granulaire kernel ET pas de syscall ca va être dur.
Je constate qu'avec shm, les variables privées le restent sans avoir à utiliser de syscall à chaque fois qu'on y accède, ce qui serait évidemment très mauvais pour les performances.
Un syscall mutex ne permet absolument pas d'empecher les variables privées d'être accédées par une autre thread malicieuse.
D'ailleurs, juste avant un syscall, la thread T1 peut modifier les données qui seront envoyées en paramètre du syscall par T2. Et juste après un syscall, la thread T1 peut modfier les données reçues du syscall par T2.
Aucun syscall ne peut permettre la séparation des privilèges pour les threads.
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Je constate qu'avec shm, les variables privées le restent sans avoir à utiliser de syscall à chaque fois qu'on y accède, ce qui serait évidemment très mauvais pour les performances.
Alors
a) accès ressources ou variables privées ?
b) séparation de privilèges ou isolations de processus ?
c) partage SHM protégé par GID/UID kernel ou autre de matériel ?
Non parceque là il va falloir choisir. Tu te places dans un cas pour lequel certes ma solution n'importe rien, mais qui d'un autre coté n'a rien a voir avec le problème posé initialement; dans le sous sous sous thread en cours je pensais naivement suite à ta correction que l'on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Et tu contre mon argumentation en me parlant de variables privées protégés par hardware au niveau des processus.
Un syscall mutex ne permet absolument pas d'empecher les variables privées d'être accédées par une autre thread malicieuse.
Alors le syscall mutex, c'est celui qui fait des boucles atomiques ? Ou alors je joue encore sur les mots ? Et les variables privées de thread tu peux t'étendre un peu ?
On parle d'un Mutex (qui a été posé par un syscall et qui va être enlevé par un syscall certes, mais là il est présent il bouge pas).
On va dire que ce que tu voulais dire était Un kernel check sur un mutex ne permet absolument pas d'empecher une ressource partagée d'être accédées par une autre thread malicieuse.
A quoi on peut dire ceci :
a) si le mec est assez doué pour avoir suffisament pété les sécurités du systèmes pour pouvoir forcer un processus à spawner un nouveau thread malicieux on est pas beau. Si ce n'est pas un hacker surdoué c'est un programmeur bon à mettre à la poubelle.
b) On reprend rapidement le principe standard des mutex.
En mode normal : mutex M1 posé par le processus P1. Il existe aussi un processus P2. Lors de l'accès ressource le kernel vérifie si il y a un mutex dessus, et si il y a mutex il compare les droits du processus avec ceux du mutex.
Bref on a d'un coté (notation super cavalière mais ca ira)
M1$P1 et de l'autre P1. Si il y a accès de P1 su M1 ca passe., si il y a accès de P2 sur M1 ca casse.
Maintenant le même avec SELinux : On dit au kernel de ne pas tester seulement contre le processus, mais aussi contre le domaine.
Donc On a un seul process P1 avec T1 et T2. T1 appartient au domaine D1 et T2 au domaine D2.
Si T1 pose un mutex M1 sur une ressource celui ci aurait comme "clef" P1D1 donc pour reprendre notre affreuse notation :
M1$P1D1. Si T2 essaye de toucher à ce lock il se fera jeter car il arrivera du domaine D2 et aura donc une signature P1D2 incompatible avec M1.
D'ailleurs, juste avant un syscall, la thread T1 peut modifier les données qui seront envoyées en paramètre du syscall par T2.
Tout a fait, un process codé avec les pieds peut faire n'importe quoi. Mais j'ai du mal à y voir une spécificité des threads. Et ensuite, si le syscall est uen demande de pose de mutex, tu vas changer la demande de pose de mutex ? Tu vas faire faire un lock par T2 sur une autre ressource ? (si tant est qu'il peut). LOOOTTT !
Et juste après un syscall, la thread T1 peut modfier les données reçues du syscall par T2.
La faille ultime ! Au moment ou le kernel retourne le résultat du syscal vers le thread, tu interromps le kernel, tu redirige le thread cible sur toi Tu remplace le résultat par des marmottes, tu passe dans le Go kernel space et tu le renvoit au thread T2 en syscall. Noublie pas le papier cadeau autour c'est plus joli. Et là T2 sera persuadé que son syscal a échoué alors qu'en vrai il a réussi \o/.
Je pense que je vais me ranger à l'avis de pbpg et Frederic RISS ...
Kha
root est un privilège, pas un droit !
[^]Re: Séparation des privilèges impossible avec threads actuelles !
on parlait de ressources partagées en utilisant les méccanismes kernels de séparation de privilèges
Il est évident que les shm permettent à 2 processus P1 et P2 de communiquer via des variables partagées tout en protégeant les variables privées de P1 et P2.
Par conséquent si P1 est malicieux, il ne pourra pas accéder aux variables privées de P2 pour détourner les privilèges de P2 sur la ressource R non partagée (par exemple R est un fichier accessible uniquement à P2).
Ceci étant ma définition (pas que la mienne) de séparation de privilèges. Un privilège étant, par définition, une ressource qui n'est pas partagée par tous.
Tu retrouves ce système de séparation (avec communications par shm ou pipes ou sockets) dans de nombreux softs Unix sécurisés.
Tu ne peux pas faire cela pour R avec des threads T1 et T2 appartenants au meme process. Il n'y a donc pas de séparation de privilèges possible avec les threads.
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Tu ne peux pas faire cela pour R avec des threads T1 et T2 appartenants au meme process. Il n'y a donc pas de séparation de privilèges possible avec les threads.
Alors
a) Si tu arrives à créer un thread malicieux bravo.
b) Si ton privilège est sur un groupe ou un user et non sur le process, tu auras exactement les mêmes failles sur deux process P1 et P2 ayant même GID et même UID. (N.B si ce n'est pas le cas ce n'est pas un privilège, c'est une donnée privée)
c) Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
d) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
e) Inutile de hurler des définitions que je connais déjà quand je pars du principe que tu confonds deux choses distinctes, surtout si il s'avère quatre posts plus bas que j'avais raison.
Kha
root est un privilège, pas un droit !
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Si tu arrives à créer un thread malicieux bravo.
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
Si ton privilège est sur un groupe ou un user et non sur le process,
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié. Et ça ne coute rien en CPU supplémentaire.
Si tu as envie de placer des signaux dans tous les sens pour protéger tes variables dans les threads, c'est possible.
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
) Si tu as un environement SE Linux tu peux protéger tes ressources/variables/accès aussi finement sur des threads que sur des process.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
[^]Re: Séparation des privilèges impossible avec threads actuelles !
Ce n'est pas plus dur de provoquer des overflows (et d'autres failles) dans un thread que dans un process !
J'ai prétendu le contraire ? Ca n'est pas alors un thread malicieux, mais une faille dans un thread existant. Par contre injecter un thread malicieux dans un processus ets infiniment plus complexe que d'injecter un processus malicieux dans un système.
Tous les programmes utilisant la séparation de privilèges (comme ssh ou X) utilisent évidemment des uid/groups spéciaux pour le process privilégié.
Donc la séparation des droits se fait au niveau logiciel et non au niveau matériel et c'est aussi sensible aux attaques que les threads
T2 ne peut pas empêcher un T1 malicieux d'accéder à une variable privée de T2 avec un signal.
Si cf les trois exemples dans les posts précédents.
En userspace, tu ne peux pas empêcher T1 de modifier les variables privées de T2 pour forcer T2 à utiliser R malicieusement.
Si, cf les trois exemples dans les posts précédents.
Kha
root est un privilège, pas un droit !
[^]ajout d'un nouveau message tout en bas de la page
Je te réponds en ajoutant un nouveau message tout en bas de la page.
[^]Re: ajout d'un nouveau message tout en bas de la page
Le message est accessible en cliquant sur le lien qui correspond à l'article, et il n'est donc pas dans ce thread.
[^]Re: ajout d'un nouveau message tout en bas de la page
pour les flemmards, voici le nouveau thread:
https://linuxfr.org/comments/565312.html#565312(...)
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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.
Oui, et tu fais comment si tu veux liberer des segments avant ? Parce que c'est de ca que je parles.
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 !
Non justement. Avec des threads tu fais des new ou des malloc, tu les liberes quand t'as fini et c'est tout, t'as pas besoin de compter et/ou marquer tes allocations pour savoir si elles ont toutes ete liberees car la heap fait ca pour toi.
[^]malloc bugs pour threads
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.
[^]Re: malloc bugs pour threads
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.
Oui c'est un risque, mais compare au bordel qu'implique la gestion des segments c'est rien du tout.
Qu'on se comprenne bien, utiliser les threads comporte des risques de bugs comme celui-ci et d'autres, mais utiliser des segments de memoire partagee et des processus est bcp plus lourd et dangereux vu toute la cuisine qu'il faut faire pour que ca marche.
[^]Re: malloc bugs pour threads
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.
[^]Re: malloc bugs pour threads
Franchement, positionner le flag RMID dès la création d'un shm n'a rien d'une cuisine compliquée.
T'as toujours pas compris, le probleme c'est pas que le segment disparait ou pas quand tous les process ont detache le segment, le probleme c'est que le process doit faire du resource tracking pour savoir quand il peut detacher le segment.
[^]Re: malloc bugs pour threads
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 !
[^]Re: malloc bugs pour threads
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 + !
Totalement faux.
Dans les 2 cas, tu dois t'assurer que tu n'utilises vraiment plus la memoire avant de faire un free(free reel dans le cas multithread, wrapper free dans le cas shm)
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.
Bref :
threads : alloues et liberes buffer avec malloc/free, et la heap se charge de savoir quand les gros blocs qu'elle alloue peuvent etre liberes vu qu'elle fait son propre resource tracking.
shm: alloues et libere les buffers dans le segment avec un malloc/free proprio qui doit faire le resource tracking a la place de la heap pour savoir quand le segment peut etre desalloue.
Dans le 2eme cas tu es clairement oblige de faire ton propre resource tracking vu que tu peux pas utiliser la heap d'origine pour ca.
Serieusement, j'ai assez d'experience avec les 2 architectures pour savoir que la methode segments partages n'est tout simplement pas une solution de remplacement viable en general pour les threads, ca peut etre utile dans certains cas mais c'est tres tres loin d'etre le cas generalement.
[^]Re: malloc bugs pour threads, voir plus bas
Je te réponds plus bas, car là ça devient illisible.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
Euh juste une precision sur l'aspect 'POSIX'
les appels shmget, shmctl, etc... NE SONT PAS POSIX mais sysV.
Les appels POSIX correspondant s'appellent
shm_open, shm_unlink, etc...
Les threads 'classique' sous linux sont eux POSIX d'où leur nom
pthread (p = POSIX).
A noter que si les différents groupe de travail POSIX on vu un
intérêt aux 2 API:
shm_XXX
pthread_XXXX
c'est bien qu'elle ont leur raisons d'être toutes les 2.
J'ai mon avis à ce sujet mais je vais lire un peu plus la discussion
pour éviter les re-dites.
Juste un exemple au passage, j'utilise COURAMMENT
les threads POSIX avec des SEGMENT de mémoire partagées
POSIX ou sysV il n'y a pas d'opposition entre les 2.
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
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
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
Oui je savais mais j'avais raté ce XSI.
Quoi que c'est peut-être jouer sur les mots
mais il me semble que ce dont tu parles est plutôt
"Single Unix Specification" que POSIX.
Sauf erreur de ma part sur opengroup.org on peut
consulter cette "Single Unix Specification" (SUS) et pas
POSIX.
A moins que j'ai raté l'info qui dirait
que SUS soit le standard successeur des différents volets POSIX?
[^]Re: vs POSIX shared memory,pointeurs,RMID,spin
XSI Interprocess Communication, Realtime, shmat(), shmctl(), shmdt(), shm_open(), shm_unlink(), the Base Definitions volume of IEEE Std 1003.1-2001, <sys/shm.h>
UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[^]malloc bugs pour threads, voir plus haut
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.
[^]Re: malloc bugs pour threads, voir plus haut
Tu ne comprends toujours pas de quoi je parles.
Il y a plusieurs etapes :
1) Tu alloues de gros blocs de memoire pour pouvoir allouer tes buffers a l'interieur
2) Tu alloues des petits blocs memoire a l'interieur de ces gros blocs pour utilisation habituelle
3) Tu utilises la memoire allouee
4) Tu liberes les petits blocs quand tu n'en as plus besoin
5) Tu tient une comptabilite des blocs pour savoir quand toutes les allocations d'un gros bloc ont ete liberees
6)Quand toutes les allocations d'un gros bloc ont ete liberees, le gros bloc peut etre desalloue
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
cas shm:
Tu dois tout refaire a la main car la heap ne supporte pas les segments de memoire partagee
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.
C'est faux, exemple tres simple :
- Un segment partage de 64Ko est utilise par plusieurs process pour les allocations partagees
- Process A fait une allocation de 30 bytes dans ce segment, remplit le buffer et l'envoie a B
- Process B fait une operation sur le buffer, le met de cote pour faire autre chose, et va revenir a ce buffer plus tard
- Au bout d'un moment, process A libere l'allocation car lui n'en a plus besoin
- Process A fait une _autre_ allocation pour une autre operation, et par malchance celle ci se retrouve par dessus l'allocation precedente(possible car cette zone memoire est marquee comme libre vu qu'elle a ete liberee)
- Process A ecrit qqe chose dans cette allocation
- Process B qui a toujours un pointeur sur le buffer du debut le lit, et y trouve n'importe quoi --> il plante
C'est _exactement_ le meme probleme qu'avec les threads.
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.
Oui, ca devient le cas super ou tu te retrouves avec des pointeurs situes dans 2 mondes totalement differents et qu'il faut etre sur que tu ne passes pas un pointeur de ton propre espace a un autre processus ==> risque de bugs supplementaire
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.
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).
Quand a reutiliser la majeure partie du code de malloc/free, t'as pas idee de la complexite des ces elements et du cout que cela implique de devoir les modifier, sans parler du risque d'introduire des bugs la aussi.
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.
Ces gaspillages sont enormes si tu n'utilises pas le meme segment pour plusieurs allocation et la complexite de l'operation dans son ensemble rend les risques de bugs bien plus eleve qu'avec les threads.
Serieusement, je suis persuade que tu n'as jamais essaye de developper un soft un tant soit peu complexe avec les shm, il est plus qu'evident qu'ils ne sont pas un remplacement realiste aux threads apres un minimum d'utilisation. Ils ont une utilite mais ce n'est pas de remplacer l'architecture a base de threads, c'est pas fait pour.
[^]Re: malloc bugs pour threads, voir plus haut
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 !
[^]Re: malloc bugs pour threads, voir plus haut
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.
[^]malloc freshmeat