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. La version actuelle ne fonctionne que sur IA-32 et ses possibilités d'analyse sont limitées.
Il est prévu d'améliorer les outils d'analyse des traces générées (options de filtrage...), de porter sur IA-64 et PPC et d'étendre les traces à toutes les fonctions importantes.
L'application à tracer est lancée par une commande qui démarre un démon.
Celui-ci récupère les traces envoyées par la NPTL et les écrit dans un fichier binaire de trace.
La communication entre le démon et la NPTL se fait à l'aide d'un buffer en mémoire partagée et d'opérations atomiques.
Le fichier de trace obtenu peut être analysé par la suite sous différents formats textuel ou graphique (avec Pajé).
Plus d'information sont disponibles sur le site ou dans l'archive.
Aller plus loin
- PTT (20 clics)
- NPTL Tests and Trace (11 clics)
- NPTL (wikipedia) (11 clics)
- LTT (4 clics)
- Pajé (5 clics)
# vs POSIX shared memory
Posté par free2.org . Évalué à 4.
[^] # Re: vs POSIX shared memory
Posté par dcp . Évalué à 7.
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
Posté par free2.org . Évalué à 5.
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
Posté par dcp . Évalué à 3.
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
Posté par free2.org . Évalué à 5.
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
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
[^] # Re: vs POSIX shared memory, X
Posté par free2.org . Évalué à 2.
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
Posté par Matthieu Lemerre (site web personnel) . Évalué à 5.
http://l-lang.org/ - Conception du langage L
[^] # Re: vs POSIX shared memory, X
Posté par galactikboulay . Évalué à 6.
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
Posté par free2.org . Évalué à 2.
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
Posté par Vincent Danjean . Évalué à 2.
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
Posté par free2.org . Évalué à 2.
[^] # Re: vs POSIX shared memory, X, nouvelles threads
Posté par galactikboulay . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 1.
_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.
[^] # Re: vs POSIX shared memory, X, nouvelles threads
Posté par galactikboulay . Évalué à 3.
???? 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
Posté par Jerome Herman . Évalué à 2.
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...
[^] # Re: vs POSIX shared memory
Posté par pasBill pasGates . Évalué à 7.
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
Posté par free2.org . Évalué à 3.
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
Posté par pasBill pasGates . Évalué à 3.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 2.
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
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 3.
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.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 2.
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).
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par free2.org . Évalué à 2.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par Jerome Herman . Évalué à 2.
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.
[^] # mmap n'a pas pas de RMID
Posté par free2.org . Évalué à 2.
Et je ne vois pas ce que les mutex viennent faire là dedans.
[^] # Re: mmap n'a pas pas de RMID
Posté par Jerome Herman . Évalué à 2.
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.
[^] # Re: mmap n'a pas pas de RMID
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 2.
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.
[^] # mmap ANONYMOUS n'a aucun surcout
Posté par free2.org . Évalué à 2.
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
Posté par Vincent Danjean . Évalué à 2.
Ç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
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 2.
Tout à fait et je le maintiens
Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage
En user mode, même pas en rêve. Entre deux processus c'est le mur direct.
Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.
Pas du tout. Un pthread_spinlock a des inconvennients mais rien de comparable avec un spinlock de processus. Un pthread_spinlock n'est pas un while(1), c'est un event catcher. Ca n'a rien à voir ni en terme de charge ni en terme d'utilisabilité. Avec un pthread_spinlock tu as les retry, le test et le lock qui viennent de façon atomique. Rien que çà ca fait une ennorme différence.
Comme quelqu'un l'a suggéré un peu plus bas, il n'y a aucune différence au niveau OS entre la synchro de processus partageant de la memoire, et la synchro des threads
Le post de fin de thread pose un des résultats de notre discussion comme une évidence. J'ai donc préféré ne pas répondre.
C'est juste les bibliothèques en surcouche qui ont l'air différentes
Non, je t'assure qu'avoir un seul process au lieu de deux fait un différence réelle qui remonte jusqu'au hardware. ce n'est pas juste une illusion maintenue par du logiciel.
Synchorniser deux threads entre eux est un jeu d'enfant en utilisant readlock/writelock.
Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).
Alors dans le cas de processus en user space on en peut pas se contenter de boucler pour faire de l'attente active. Ca ne marche pas (on n'aura jamais un accès au segment atomique) il faut boucler + syscall (en d'autres termes faire un syscall immédiatement après la réalisation de la condition de test pour locker la ressource)
On peut par contre faire de l'attente passive en trhead sans jamais utiliser le moindre syscall grace aux signaux internes. Ca fonctionen comme un signal syscall, sauf que c'ets généré par le processus lui même à destination exclusive de ses trheads. Ca marche très bien.
[^] # Re: mmap ANONYMOUS n'a aucun surcout
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 2.
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.
[^] # scheduling intra process, voir plus bas
Posté par free2.org . Évalué à 2.
[^] # Re: scheduling intra process, voir plus bas
Posté par Jerome Herman . Évalué à 2.
Je dois être mauvais en jeux de piste, j'ai pas trouvé de post postérieur à 23:36...
[^] # Re: scheduling intra process, voir plus bas
Posté par free2.org . Évalué à 2.
[^] # scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par free2.org . Évalué à 2.
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é
Posté par Jerome Herman . Évalué à 2.
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.
[^] # Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par free2.org . Évalué à 2.
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é
Posté par Jerome Herman . Évalué à 2.
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.
[^] # séparation des privilèges
Posté par free2.org . Évalué à 2.
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
Posté par Jerome Herman . Évalué à 2.
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.)
[^] # Re: séparation des privilèges
Posté par free2.org . Évalué à 2.
>>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
Posté par Jerome Herman . Évalué à 2.
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.
[^] # Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . Évalué à 2.
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 !
Posté par Frédéric RISS . Évalué à 1.
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 !
Posté par free2.org . Évalué à 2.
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 !
Posté par Jerome Herman . Évalué à 2.
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.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . Évalué à 2.
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 !
Posté par Jerome Herman . Évalué à 2.
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 ...
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . Évalué à 2.
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 !
Posté par Jerome Herman . Évalué à 2.
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.
[^] # Re: Séparation des privilèges impossible avec threads actuelles !
Posté par free2.org . Évalué à 2.
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 !
Posté par Jerome Herman . Évalué à 2.
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.
[^] # ajout d'un nouveau message tout en bas de la page
Posté par free2.org . Évalué à 2.
[^] # Re: ajout d'un nouveau message tout en bas de la page
Posté par free2.org . Évalué à 2.
[^] # Re: ajout d'un nouveau message tout en bas de la page
Posté par free2.org . Évalué à 2.
https://linuxfr.org/comments/565312.html#565312(...)
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 2.
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
Posté par free2.org . Évalué à 2.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par NOULARD Eric (site web personnel) . Évalué à 2.
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
Posté par free2.org . Évalué à 2.
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
Posté par NOULARD Eric (site web personnel) . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
UNIX ® is a registered Trademark of The Open Group.
POSIX ® is a registered Trademark of The IEEE.
[^] # malloc bugs pour threads, voir plus haut
Posté par free2.org . Évalué à 2.
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
Posté par pasBill pasGates . Évalué à 1.
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
Posté par free2.org . Évalué à 2.
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
Posté par free2.org . Évalué à 2.
[^] # malloc freshmeat
Posté par free2.org . Évalué à 2.
http://freshmeat.net/search/?q=malloc§ion=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.
[^] # Re: malloc bugs pour threads, voir plus haut
Posté par pasBill pasGates . É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.
[^] # le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
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.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . Évalué à 2.
2. Sécurité/fiabilité: libérer une zone utilisée par les autres threads peut produire des bugs silencieux.
1) C'est clair que si on appelle un mutex système on a une consomation de CPU et de mémoire supplémentaire, mais alors on est protégé de façon complète. Ceci étant ca ne consomme pas plus qu'un mutex sur SHM (exactement la même chose en fait)
2) Là c'ets un problème de programation. Déjà si on est passé par un mutex système il faut vraiment le faire exprès pour le faire sauter par un autre thread. Par contre si on est passé par un simple lock interne on est obligé de suivre attentivement le thread lockeur sois-même, masi d'una utre coté si on passe par un lock interne on a pas d'overhead mémoire ou CPU.
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).
Tout à fait, mais aucune sous allocation multiprocess ne peut aller aussi vite qu'une sous allocation multi-threads. La mémoire est beaucoup plus facile à réutiliser en mode thread qu'en mode process. Un modèle d'allocation par doublage par exemple prend deux lignes en threads mais necessite du code pointu en shm.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
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.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . Évalué à 1.
Mais ce mutex ne résoud absolument le probleme d'une thread qui libere par inadvertance une zone mémoire qui sera encore utilisée par une autre thread.
C'est pas un mutex mais un spinlock(grosse difference) et le probleme est le meme avec le multi-processus, un processus qui libere par inadvertance une zone utilisee par un autre processus ca tourne aussi a la catastrophe comme te je l'ai montre plus haut
Et pourquoi ? Toute sous-allocation doit se faire sans syscall. En utilisant exactement le meme code de sous-allocation dans un process ou dans une thread, on a exactement la meme performance.
La difference etant que tu ne peux pas synchronizer des processus differents avec des spinlocks a moins de faire une cuisine gigantesque, donc tu dois te taper des mutex, qui sont 10x plus lents que les spinlocks --> perfs plus mauvaises.
Sans parler du probleme suivant :
Processus A cree un segment de memoire partagee a l'addresse 0x800A0000 pour y faire des allocations partagees et les passer au processus B
Processus B a une libraire chargee a l'addresse 0x800A0000, et donc ne peut pas mapper le segment a cette addresse.
--> Processus B ne peut pas utiliser directement les pointeurs sur le segment de memoire partagee passes par A, il doit decaler les pointeurs a l'endroit ou il a pu mapper le segment.
Je te le dis et redis, essaies toi meme et tu t'en rendras compte, c'est pas viable comme solution.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
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.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . Évalué à 1.
Mais je me demandes si tu comprends meme ce que je te dis, je parles pas de detacher un segment, je parles de desallouer un petit bloc dans un segment, cf. plus haut l'exemple
Attend, y'a pas plus simple qu'un spinlock.
http://en.wikipedia.org/wiki/Spinlock(...)(...)
La encore plein de biblios libres sont disponibles.
T'as vraiment un mal fou a faire la part entre la theorie, qui est bien jolie, et l'implementation pratique dans notre cas precis. Les biblios elles sont mignonnes, mais si elles repondent pas exactement aux besoins ca implique de la cuisine pour adapter, des perfs mauvaises, ...
Et de toutes façons un spinlock ça boucle donc c'est à éviter au maximum dans un algo.
Serieusement, t'as deja fait de la prog. multithread ? Plus je te lis plus j'ai l'impression que tu n'as absolument aucune idee du sujet.
Les spinlocks sont un moyen hyper efficace de locker des sections de code petites et peu embouteillees, c'est facilement 10x plus rapide qu'utiliser un mutex vu qu'il n'y a pas de context-switch.
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.
Ben oui c'est genial, t'as donc le choix entre :
a) Devoir tout allouer avant que le soft demarre, ce qui est totalement irrealiste
b) Devoir faire du decalage a chaque dereferencement ce qui est un merdier pas possible car plusieurs segments peuvent avoir des decalages differents.
Serieusement, je t'en prie, avant de parler d'un sujet dans lequel tu n'as manifestement aucune experience pratique, essaie toi meme, tu t'en rendras compte tres vite que c'est absolument pas fait pour remplacer des threads.
Sur ce, j'arretes la discussion la, ca tourne en rond et tu ne comprends manifestement pas les problemes causes par les shm.
[^] # processus indépendant et communiquant, la base de la fiabilité des Unix
Posté par free2.org . Évalué à 2.
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.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . Évalué à 1.
Je te rappelle que l'article concerne la complexité du debuggage des threads.
Quedalle, debugger des threads concurrents c'est tout aussi complique debugger des processus concurrents, meme topo.
La question c'est laquelle des 2 architectures est la meilleure pour eviter des bugs et avoir des perfs decentes.
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.
Rien du tout, la complexite du debuggage est la meme, mais bien evidemment tu ne le sais pas car tu n'as jamais essaye toi meme.
Le partage des donnees, que ce soit des threads ou processus avec shm c'est le meme topo.
Enfer qui est incommensurablement plus grand que d'avoir à utiliser une bibliotheque pour les allocations et une bibliotheque pour les spinlocks.
Mais tu fais expres c'est pas possible...
Le seul fait de devoir faire des decalages pour les pointeurs si les segments ne peuvent etre mappes au meme endroit fait que la solution shm est totalement irrealiste, partant de la la question ne se pose meme pas, mais tu refuses de comprendre et t'obstines a croire une theorie que tu n'as jamais eprouvee plutot qu'ecouter qq'un qui a deja teste les 2 techniques.
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.
Ca c'est une conclusion qui prouve que tu n'as absolument rien compris au probleme.
Les shm oui c'est utile pour remplacer les pipe ou socket(dans certains cas), mais ca n'a rien a voir avec les threads et cela ne les remplace pas, pour la tres simple raison que les pipe et socket ca n'a jamais ete une alternative aux threads, c'est pour un usage different.
Je t'en prie, arretes de parler de maniere si affirmative d'une technologie que manifestement tu n'as jamais utilisee, ce que tu racontes est reellement effarant.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par free2.org . Évalué à 2.
Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.
Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.
Si tu veux encore une réponse, essaye d'être un peu plus correct.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . Évalué à 1.
Je suis pas insultant, mais tu occultes totalement les problemes et refuses de voir la verite en face: c'est infaisable dans le monde reel, donc forcement au bout du 10eme argument que tu evites je m'enerves un petit peu.
Unix a 35 ans. Il a acquis sa réputation de fiabilité et d'efficacité en utilisant surtout des process indépendants et communiquant par pipe ou socket. C'est encore vrai aujourd'hui. Et les 20 premières années d'Unix étaient complètement dépourvues de threads.
Oui, et pendant 50 ans les voitures n'ont pas eu d'airbags, ca veut dire que les airbags sont dangereux ? Non, ca n'a rien a voir. De meme avec Unix, le fait qu'Unix ait eu des process independants au debut n'a rien a voir avec sa reputation de fiabilite, c'etait simplement du au fait que les threads n'etaient pas encore implementes.
Je dis simplement que nous devons tirer les leçons de fiabilité de l'histoire d'Unix, et tout simplement remplacer les pipe et les sockets par des shm qui sont plus rapides.
Les pipe et socket oui c'est possible dans bcp de cas(pas tous), mais remplacer les threads pas du tout, c'est totalement different et c'est pratiquement irrealisable.
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par free2.org . Évalué à 2.
Exemple parfait.
Justement, Unix a toujours a toujours eu un airbag très fiable: les variables privées sont inacessibles. C'est exactement ce qui assure sa sécurité.
Quand à comparer à une "invention" la communication par mémoire partagée des threads, la shared memory existait déjà pour les processus. Je ne vois pas en quoi ne plus pouvoir avoir de variables vraiment privées serait un progrès.
Surtout si c'est pour économiser quelques instructions de contextes (quasi identiques dans le cas d'un père shm et ses fils) tous les dixièmes de seconde (selon la slice). Je ne suis pas prêt à sacrifier la fiablité de mon système pour un gain aussi négligeable !
[^] # Re: processus indépendant et communiquant, la base de la fiabilité des U
Posté par pasBill pasGates . Évalué à 1.
Je m'arretes la car on tourne en rond, je n'ai qu'une chose a te dire : Essayes par toi meme plutot que disserter sur une theorie que tu n'as jamais teste, et tu comprendras pourquoi la majorite de la planete utilise des threads plutot qu'une archi multi-processus, il y a de bonnes raisons a cela et tu t'en rendras compte en essayant d'implementer une archi multi-processus.
[^] # délai pour corriger une faille de sécurité, pour tester dynamique thread
Posté par free2.org . Évalué à 2.
Tu jettes ton masque :)
Justement, beaucoup d'utilisateurs de windows aimeraient bien que l'architeture multithread de win déconne moins souvent, et avec moins de failles de sécurité publiques non corrigées depuis trop longtemps. Pourquoi ne sont-elles pas corrigées rapidement ? Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Tu peux arreter de raconter des conneries STP ?
1) Cites moi des failles publiques non corrigees dans Windows(je parles pas d'IE qui est un browser)
2) Cites moi donc des failles dans l'archi multi-thread de Windows
Ce que tu racontes la c'est 100% conneries, du vent, rien d'autre et soit tu le sais, soit tu vis sur la lune mon cher.
Parce que le moindre changement peut perturber la dynamique des threads, cf l'article que l'on commente, et fait apparaitre de nouveaux bugs. C'est ça l'enfer des threads.
Tu ne sais absolument pas de quoi tu parles, et c'est vraiment gonflant.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
http://secunia.com/product/22/(...)
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
La typo était évidente :)
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Et a part ca, tu t'es defile encore une fois, donne moi donc ces exemples montrant que les failles dans Windows sont dues aux threads.
Mais comme d'habitude tu vas eviter de repondre je suppose et detourner le sujet sur autre chose.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par briaeros007 . Évalué à 3.
mais quand je vois "alors tu remarqueras que toutes ces soi-disantes failles reportees sont inoffensives dans l'enorme majorite(celles qu'on ne corrige pas)"
Alors si j'ai bien compris a faille qu'utilise sasser etait "inoffensive" ?
Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.
a moins que pbpg parlait uniquement des failles dues au threads. Dans ce cas ce post n'as pas lieu d'etre .
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
La faille qu'a utilise Sasser avait ete corrigee avant que le virus existe, ca n'a rien a voir donc.
Si tu regardes la liste des soi-disant failles non corrigees sur le site, tu verras qu'elles sont extremement limitees et/ou demandent des conditions tres particulieres pour etre reproduisibles, bref ne sont pas exploitables.
Je n'en sais rien sur la fait que des threads introduisent plus de failles (meme si je me permet d'emettre quelques reserves dessus) mais dire que windows est un havre de securite je trouve ca un peu ose quand meme.
Je ne dis pas que c'est un havre de securite, par contre je dis que les failles qui posent un risque on les corrige, les autres vu qu'elles ne posent pas de risque bien evidemment sont traitees differement selon les cas.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
La plupart des gens sérieux qui proposent des failles à bugtraq/CVE/secunia mettent un point d'honneur à prouver que ce qu'ils disent est vrai en fournissant un exploit à qui le demande.
En l'absence d'un "proof of concept", une faille peut difficilement être considérée highly critical. A moins d'être particulièrement évidente. Ce qui n'est pas le cas quand il faut une "race condition" pour que la faille existe. Prouver que la race condition peut se produire dans la pratique, et pas seulement en théorie, est très difficile si on a pas un exploit à proposer.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Mais c'est quand meme dingue comme on a devie du sujet principal sur un sujet qui n'a _absolument rien_ a voir car pour je ne sais quelle raison bizarre et que tu n'as toujours pas expliquee et prouvee tu as dit que les failles de securite dans Windows etaient causees par les threads.
Ca serait franchement bien que tu mettes quelques arguments valables dans tes dires, parce que quand je te lis j'ai l'impression que tu ne fais qu'une chose : tu lis la theorie et tu extrapoles sans jamais avoir touche a la pratique.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
La question n'est pas combien. Une seule faille critique connue et exploitable suffit amplement à bousiller toute la sécurité d'un système.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Faudrait penser a faire un peu plus que de la lecture et mettre les mains dans le cambouis mon cher si tu veux que je te prennes au serieux, il n'y a jamais rien pour soutenir tes dires.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
Microsoft Windows XP Professional with all vendor patches installed and all vendor workarounds applied, is currently affected by one or more Secunia advisories rated Highly critical
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
Je n'ai jamais vu XP sans au moins une faille critique connue non corrigée présente.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
- Tu pretends que les failles sont dues aux threads, et hop, rien pour justifier
- Tu pretends qu'il y a plein de failles non corrigees dans Windows, et hop, rien pour justifier
Serieux, t'en as pas marre de sortir des conneries et te defiler a chaque fois ?
Maintenant, soit tu me justifies ce que tu as sorti, c'est a dire :
- Les failles sont dues au systeme de threads
- Les failles critiques ne sont pas corrigees
Ou alors svp tu te tais et tu arretes de sortir connerie sur connerie.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
A quel endroit j'ai dit que toutes étaient dues au threads ?
Tu pretends qu'il y a plein de failles non corrigees dans Windows, et hop, rien pour justifier
Désolé que tu comprennes pas, mais tous ceux qui fréquentent régulièrement cette page Secunia ont compris, eux. Tous les jours où on visite cette page, on peut y constater que chaque jour on peut rentrer par effraction dans un systeme XP. Point.
Je n'ai pas d'archive du site Secunia. Et je ne vais pas en chercher une pour tes beaux yeux. Mais tous ceux qui visitent cette page régulièrement savent qu'il n'y a quasiment jamais de jour sans que XP soit crackable à l'aide d'une faille critique.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Ou ai-je parle de toutes les failles ?
Désolé que tu comprennes pas, mais tous ceux qui fréquentent régulièrement cette page Secunia ont compris, eux. Tous les jours où on visite cette page, on peut y constater que chaque jour on peut rentrer par effraction dans un systeme XP. Point.
Tu continues a te defiler, files moi ces liens ou arretes de sortir des conneries !
Je n'ai pas d'archive du site Secunia. Et je ne vais pas en chercher une pour tes beaux yeux. Mais tous ceux qui visitent cette page régulièrement savent qu'il n'y a quasiment jamais de jour sans que XP soit crackable à l'aide d'une faille critique.
Ah parce que t'as besoin des archives pour me montrer ce qu'il se passe aujourd'hui ? Le lien que tu as donne ( http://secunia.com/product/22/(...) ) recense les failles jusqu'a 2002, t'as besoin de plus que ca ? Tu te fous de moi ?
Aies un minimum de bonne foi et reconnais que tu as raconte n'importe quoi.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
Mais puisque toi tu aimes les archives, cite moi une période où il n'y avait pas de failles critiques non corrigées !
Comme par hasard, et alors que tu prétendais le contraire, on est dans une période où les failles crtiques connues sont pas corrigées.
Etant un lecteur régulier, je sais que ce n'est pas un hasard.
Mais de toutes façons tous ceux qui lisent ce thread ont bookmarké cette page et pourront voir par eux-même !
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Mais puisque toi tu aimes les archives, cite moi une période où il n'y avait pas de failles critiques non corrigées !
J'ai rien a te citer moi, c'est a toi de prouver tes dires, et depuis le debut du thread tu te defiles.
Comme par hasard, et alors que tu prétendais le contraire, on est dans une période où les failles crtiques connues sont pas corrigées.
Arretes de sortir des conneries et donne un lien sur ces failles.
C'est dingue une mauvaise foi pareille, soit tu prouves tes dires soit tu te tais, c'est pas si complique a comprendre pourtant que tu es sense avoir un minimum d'arguments valables pour supporter tes affirmations non ?
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
Vis à vis des utilisateurs de win qui ont légitimement le droit de se poser des questions très sérieuses en voyant cela, c'est à ton tour de trouver facilement une période où XP n'était pas exploitable par un cracker. Cela devrait même être très facile d'après tes propos précédents.
Si tu n'es pas capable de donner une période sans exploit maintenant, tu ne respectes pas les utilsiateurs de win qui sont inquiets par la facilité avec laquelle j'ai trouvé une période exploitable.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par free2.org . Évalué à 2.
Et la date de correction effective n'est pas si évidente dans les archives de Secunia.
T'as trouve qu'un jour, il y a eu une faille
Pas n'importe quel jour. Comme par hasard maintenant on peut cracker XP, et depuis au moins tous les jours que cette thread dure (et au moins depuis que les failles critiques actuelles non corrigées sont connues).
Et comme par hasard à chaque fois que je visite Secunia, c'est le cas.
[^] # Re: délai pour corriger une faille de sécurité, pour tester dynamique th
Posté par pasBill pasGates . Évalué à 1.
Mais c'est genial ! T'as trouve qu'un jour, il y a eu une faille et donc que XP etait exploitable, si tu veux je te listes un tas de cas ou Linux, Solaris, ... etaient expoitable aussi.
Si tu n'es pas capable de donner une période sans exploit maintenant, tu ne respectes pas les utilsiateurs de win qui sont inquiets par la facilité avec laquelle j'ai trouvé une période exploitable.
Une periode ? Tres simple, ton lien : http://secunia.com/product/22/(...)
Entre le 13 octobre 2004 et le 25 decembre 2004, aucune faille importante n'a ete recensee dans XP, entre le 8 fevrier et le 14 avril non plus, ... Il suffit de regarder les dates de release des vulnerabilites.
Je te l'ai montre, tu racontes n'importe quoi, et tu as meme donne le baton toi-meme pour te faire battre.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . Évalué à 2.
Mais ca fait un call à un mutex. après on peut se débrouiller en interne.
Par exemple, je sais que mon prog en charge pleine bouffe 200Mo. Donc je fais dans mon thread un malloc de 200Mo d'entrée de jeu (et même le plus souvent un calloc par choix perso) et après je gère ma mémoire en interne sans refaire le moindre malloc ni le moindre appel a des signaux systèmes. J'ai fait un malloc et je distribue ensuite au threads qui ont en besoins ce qu'ils me demandent quand ils le demandent. Niveau vitesse je gagne en perf un maximum.
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.
Gni ? Quand je sous alloue d'un process vers un de ses threads je fais exactement 0 appels systèmes. Quand je lock un segment via un thread encore 0 appels. Quand je remonte un signal interne pour la libération d'une ressource toujours 0.
Niveau perf j'ai un facteur temps qui varie de 3 à 15 suivant la charge (à nice de 0).
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :) Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
Quand je sous alloue d'un process vers un de ses threads je fais exactement 0 appels systèmes
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
Quand je lock un segment via un thread encore 0 appels.
Alors tu utilises forcément un spinlock, bien que tu ne les aimes pas d'après un de tes messages un peu plus haut. Sache que le principe des spinlocks fonctionne exactement pareil dans un shm. Aucune différence.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Sauf que les process ont le droit d'avoir des variables strictement privées !
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . Évalué à 2.
Pas du tout, PBPG dit juste qu'on ne peut pas gérer 20 000 handles SHM initialisés avec un malloc standard. C'est une question purement théorique vu que le mmu est limité à 4096 segments partagés de toute façon (en archi x86, je doute que ce soit beaucoup plus sur les autres archis). Donc la question en se pose pas. Mais si elle se posait il aurait probablement raison.
Je suis entierement d'accord que c'est la méthode la plus rapide, et tu peux aussi gérer toi-même de très gros segments partagés avec shm sans avoir besoin de passer par un équivalent de malloc !
En SHM ca n'est pas évident du tout. Il faut soit passer par des ID ayants des droits très différents et transférant ces droits aux processes qui le réclament (mais là on ne peut pas sous-allouer) ou alors créer un système pseudo-lock sur un sous segment et s'assurer que seul le processus qui a fait la demande de sous allocation peut lever ce lock. Mais là on est plus en mode de protection hardware et techniquement du point de vue kernel/mmu tout les process qui ont accès à ce segment de mémoire partagée peuvent faire sauter le pseudo-lock. Là on est exactement dans le même cas que dans les threads ou le lock est purement informatif et non portecteur.
Quand je sous-alloue à l'intérieur d'un gros shm, 0 appels systemes.
CF plus haut, dans ce cas tu perds forcément la protection mmu si chère à ton coeur
Alors tu utilises forcément un spinlock,
GNI ??? Un spinlock n'est pas un lock, c'est un méccanisme d'attente en attendant la libération d'une ressource , il faut faire un vrai lock dérrière si on veut "protéger" la ressource, ou s'assurer que els manips que l'on fait aprés le succès du spinlock sont atomiques. Dans 99.99% des cas ça oblige à coder en assembleur des instructions très précise dépendante du CPU (donc niveau portabilité ....). La pose de lock par un processus (et j'admets que c'ets un vrai lock, certifié par le hardware et/ou le kernel) nécessite plusieurs appels systèmes. La pose de lock par un thread sur un segment de la mémoire du processus (et j'admet que c'ets un lock informatif que n'importe quel autre thread peut gicler) n'en consomme pas forcément.
Sache que le principe des spinlocks fonctionne exactement pareil dans un shm
Pas du tout, un spinlock process est un while(1) ou équivalent. Un pthread_spinlock est un event catcher. Si l'évènement ne c'est pas présenté le thread passe la main au thread suivant. Ca change beaucoup de choses.
Encore une fois, en regardant les page tables du systèmes, il est facile de voir que des process communiquants avec de gros shm, et des threads communiquant avec de gros mallocs, c'est exactement pareil.
Du point de vue des pages tables c'est clair, c'est juste de la mémoire allouée dont un processus se sert. Par contre du point de vue du système ca n'a rien à voir.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
Si tu arrives à faire tout ça sans faire d'apple système, cela veut dire que tu as un mini-systeme avec scheduler coopératif à l'intérieur de ton process et que tu fais un appel à ce système qui consomme forcément du CPU supplémentaire.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . Évalué à 1.
25000*4k = 100 megas virtuels, à ne pas confondre avec 100 megas réeels !!!
C'est genial ca.
200'000 allocations de 32 bytes(qui apres tout n'est pas enorme) ca fait 800Mo virtuel et 200'000 handles, sachant qu'un process a un espace d'addresse de 3Go sur Linux x86 dont une partie deja est prise par les librairies utilisees par le soft, je t'explique pas comment ca va etre marrant de faire rentrer ca dans l'espace d'addressage sans parler des 200'000 handles.
Avec les threads, 200'000 allocations de 32 bytes ca fait 6.4 Mo et 0 handles....
Serieusement, t'as deja programme avec les shm ? On dirait pas.
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.
1) Le jour ou tu me feras un malloc pour shm plus rapide dans les cas habituels que le malloc de la glibc tu m'appelles et je t'offres une Ferrari, ok ?
2) Liberer une zone utilisee par un autre process avec les shm c'est dangereux aussi comme je te l'ai montre plus haut
La seule raison valable d'utiliser les threads, génératrices de nombreux bugs silencieux, est les performances.
Non, c'est aussi le fait qu'il est 10x plus simple d'ecrire un soft multithread qu'un soft avec segments partages.
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).
Certains softs oui, mais c'est loin d'etre la plupart.
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.
Et non c'est pas aussi simple : http://sources.redhat.com/ml/libc-alpha/2002-02/msg00108.html(...)
La glibc 2.3 utilises des spinlocks pour locker malloc, resultat tu ne peux pas adapter ca a un environnement multiprocess facilement vu que les spinlock devront etre modifies pour etre sur un segment partage eux aussi, et inutile de te dire que c'est un bordel a adapter vu que cela doit etre fait avant la moindre allocation dans ton soft...
Je te le dis et redis, essaies toi meme, essaie d'ecrire un soft un tant soit peu consequent et complexe de cette maniere et tu verras par toi meme, c'est tout simplement pas viable et maintenable.
J'ai vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 2.
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 ? :)
[^] # Re: le meilleur compromis performances vs sécurité
Posté par pasBill pasGates . Évalué à 1.
Et dans les cas des variables partagée tu as plein de biblios très simples.
Mais on s'en fout des variables privees, c'est 1% du probleme !
Quand aux biblios tres simples, tu me les montres ? Tu me montres a quel point il est simple d'adapter le malloc/free de la glibc pour l'adapter aux shm en adaptant les spinlocks et autres ?
Vraiment, j'ai clairement l'impression que tu n'as rien d'autre qu'une connaissance theorique des shm et aucune experience pratique.
vraiment l'impression que tu n'as jamais essaye d'utiliser serieusement les shm vu tes arguments.
T'as entendu parler de X ? :)
Tu as developpe X ? Non, tu prends juste un exemple qui est un cas particulier(car X n'est absolument pas typique d'un soft multithread normal, il a des contraintes differentes) et tu t'en sers pour te convaincre toi meme.
Je te demandes a _toi_, tu as deja fait de la programmation suivant ce mode la ? (shm entre plusieurs processus pour remplacer une archi. multithread)
Moi je suis 100% sur que tu n'as jamais developpe un soft un minimum complexe avec une architecture pareille, ca se voit clairement dans les arguments que tu donnes et qui ne tiennent pas la route dans le monde reel.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par free2.org . Évalué à 1.
[^] # Re: vs POSIX shared memory
Posté par Jerome Herman . Évalué à 4.
A mon sens ça ne sert pas à la même chose. La synchronisation de processus sensibles vai shm relève assez vite du cauchemar par exemple, le nombre de couches à traverser entre la demande d'accès à une info et la lecture de l'info est très largement supérieure également. Ceci étant shm est très rapide pour peux que els mutex/semaphores soient bien codées.
et élimine certains bugs difficiles à cerner
Ca en pose également pas mal d'autre. Tout d'abord les problèmes de droits en lecture/écritue/execution sur le segment partagé. Ensuite tous les problèmes d'accès à la ressource partagée et pour finir les bugs les plus complexes à cerner (les conditions de couses - racing conditions-rendues bizarres pour cause d'appel au système pendant la determination de la dispo) sont présents dans un cas comme dans l'autre.
(notamment quand un thread modifie par inadvertance, via un pointeur, les données privées d'un autre thread)
En théorie ce genre de choses ne devraient pas se produire si le code a été bien fait. Il vaut mieux créer un pool de variables appartenant au process père et laisser les threads taper dedans via un système de lock. Si deux threads commencent à s'échanger des infos directement, neuf fois sur dix on va dans le mur.
[^] # Re: vs POSIX shared memory
Posté par free2.org . Évalué à 2.
Tu penses à quoi ? Aux sémaphores ? Les segments et les sémaphores peuvent être hérités d'un processus père, ce qui simplifie leur utilisation.
Comme je l'explique ci-dessus, les shm read-only font très fort en matière de sécurité et de rapidité: l'accès aux données est bien-sûr direct.
Et si un pointeur mal programmé essaye de modifier ces données, sigsegv.
[^] # Re: vs POSIX shared memory
Posté par Jerome Herman . Évalué à 2.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
Ce que j'évoquais c'est le nombre d'appels systèmes à faire entre le moment ou un processus essaye de lrie ou d'écrire la mémoire d'un autre et le moment ou l'opération de lecture écriture est terminée.
Dans le cas des threads on est dans le même processus. Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon. Dans le cas de SHM le nombre de traitement est plus improtant, surtout si les segments sont filemapés. Il y en a près d'une trentaine je crois.
Ceci étant je suis un très grand fan de SHM, mais je l'utilise principalement pour me passer complètement des mutex/semaphores sur les applis qui ont besoins d'accéder très souvent a des ressoruces bien définies sur des temps très courts.
[^] # Re: vs POSIX shared memory
Posté par free2.org . Évalué à 2.
C'est bien pour çà que même si shm est très rapide, il ne sera jamais aussi rapide que les accès mémoire d'un thread.
??? sigsegv est généré automatiquement par le hardware sans ralentir quoique ce soit. Et uniquement s'il y a un gros bug qu'il vaut mieux détecter de suite.
Un processus a bien entendu le droit d'éditer sa propre mémoire. Il y a une vérif, une localisation du segment et et c'ets bon.
Justement un shm est la propre mémoire d'un processus. C'est bien ça le principe. Un système qui teste les droits du shm à chaque accès au lieu de le faire une fois pour toutes lors de l'attachement, n'est certainement pas un système POSIX.
Ceci étant je suis un très grand fan de SHM,
SHaiMe, c'est être fan :)
[^] # Re: vs POSIX shared memory
Posté par Jerome Herman . Évalué à 2.
Automatiquement par le hardware modulo memory manager quand même. Et quand le swap s'en mèle le modulo est pas négligeable.
Justement un shm est la propre mémoire d'un processus.
Oui mais il y a le processus créateur (la c'est vraiment sa mémoire) et ensuite les processus rattachés (c'est leur mémoire après un certains nombre de manips et de vérifs). Et dérrière il faut quand même vérifier qu'un des processus partageant c'ets aps amusé à mettre un lock exclusif ou en lecture seule sur le segment partagé. Et la le hardware n'aide pas, c'est le système qui fait ce genre de vérifs (et à chaque fois) . Quand on s'amuse en plus à émuler un système de protection en execution, une sécurité par domaine (au sens SE Linux) et tutti quanti on a des temps d'accès qui s'allongent assez violament.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Euh, c'est dans quelle version de POSIX ces "locks" qu'il faut vérifier même après l'attachement ? Les sémaphores sont optionels (et sont souvent remplaçables par des signaux).
Exemple simple: un père crée un ou 2 segments, éventuellement ré-attache un des 2 segments en read-only après l'avoir rempli. Fork(s). Tous les fils héritent alors de chaque segment partagé comme faisant partie de leur propre mémoire. L'éventuel flag read-only est déjà positionné dans le hardware par le père. Il n'y a plus jamais de test des droits d'accès par l'OS (l'attachement a déjà effectué par le père). Donc aucun ralentissement par rapport à un thread, qui ne propose même pas ce flag read-only hardware.
En fait c'est la seule technique POSIX que je connaisse pour avoir ce flag read-only controlé par le hardware.
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . Évalué à 2.
Correction: on peut aussi utiliser mmap à la place de shm quand les données sont stockées dans des fichiers.
Je crois bien d'ailleurs que tu as confondu shm et mmap avec ton histoire de lock exclusif . Dans le cas précis de mmap, il se pourrait l'OS vérifie les locks pouvant affecter des parties du fichier même quand on modifie sa projection en mémoire. Mais là il va falloir que je me replonge dans les specs POSIX, et on est un peu hors sujet là :)
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par aurelj . Évalué à 3.
Correction: on peut aussi utiliser mmap à la place de shm quand les données sont stockées dans des fichiers.
Effectivment on peut utiliser mmap pour avoir un flag read-only hardware. Mais ca n'est absolument pas réservé au fichiers !
Tu peux très bien allouer une simple zone mémoire en utilisant mmap en MAP_ANONYMOUS. Du coup, tu peux mapper en read-only une zone mémoire utilisé par un autre thread par example.
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . Évalué à 2.
On peut donc douter de sa portabilité.
Cependant, le jour où ce sera portable, et si la spec POSIX précise que mmap ne concerne qu'un thread et pas tous les threads, je conviens que les threads pourront alors faire ce que seuls les shm peuvent faire aujourd'hui.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par aurelj . Évalué à 2.
exact.
et est apparu récemment dans Linux.
Tout est relatif... Ca dépend de ce que tu appel récemment, mais perso, je ne pense pas que les linux < 2.4 soit encore tellement utilisé que ca, sauf cas très particulier.
On peut donc douter de sa portabilité.
Dans l'absolue ca n'est pas faux. Mais en pratique, et si tu te limite aux systèmes les plus courrant (Linux, *BSD, MacOSX, cygwin...), ca ne pose apparament aucun problème hormis le fait que certain systèmes définissent encore MAP_ANON à la place de MAP_ANONYMOUS.
Pour info, juste un example. MAP_ANONYMOUS est utilisé dans MPlayer pour allouer une zone mémoire en lui attribuant le droit PROT_EXEC afin de pouvoir executer du code qui est généré à l'execution. (sans ce PROT_EXEC, tu obtient un jolie segfault sur les CPU gérant la protection en exexecution, tel le NX bit des AMD64)
En pratique il s'avère que MPlayer ne se débrouille pas trop mal pour ce qui est de la portabilité.
Donc a moins que ta cible ne soit des systèmes vraiment très exotiques, je ne pense pas que la portabilité soit un si gros problème.
En ce qui concerne Linux, tu as essayé pour voir si les autres threads faisaient un sigsegv ?
Non, je n'ai pas fait ce genre de test avec des threads.
Les threads et autre fork c'est sympa, mais quand on peut les éviter c'est encore mieux ;-)
[^] # Re: vs POSIX shared memory, read-only, mmap
Posté par free2.org . Évalué à 2.
C'est quand-meme un gros hic ! En + il n'est pas dit que ce comportement sigsev sera identique avec tous les systèmes que tu as cité (absence de standard officiel).
[^] # Re: vs POSIX shared memory, read-only, mmap pour simplifier shm !
Posté par free2.org . Évalué à 3.
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 !
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 3.
Au niveau du process si il est en user-space je suis d'accord avec toi. Une fois le segment attaché il est là. Mais au niveau du kernel c'est un poil plus complexe, vu qu'il doit quand même faire le mapping mémoire réelle/mémoire virtuelle pour chaque processus (au lieu d'un seul appel dans le cas de threads). En mémoire virtuelle chaque process aura une adresse virtuelle différente pour le segement partagé. Même si le mapping lui même et les droits qui lui sont attribués sont bien gérés en hardware par le mmu (de façon plus ou moins heureuse suivant les architectures), les controles des segments, des locks et des unlocks se fait en externe via des syscall, alors que dans un thread posix une fois la mémoire obtenue tu n'as de compte à rendre à personne sur son utilisation du moment que tu te conformes aux droits demandés à la création.
En NTPL les locks, mutex et autres se font à l'intérieur du process sans déranger le kernel, ca réduit quand même beaucoup le nombre de syscall qui partent (juste création/changement de droits/destruction).
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 3.
Si les segments sont créés par un père, les fils héritent de son mapping automatiquement.
En NTPL les locks, mutex et autres se font à l'intérieur du process sans déranger le kernel, ca réduit quand même beaucoup le nombre de syscall qui partent (juste création/changement de droits/destruction).
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 3.
Euh non, ils héritent du même adressage virtuel (ie un pointeur vers une variable du pere aura la même valeur qu'un pointeur vers la copie de variable du fils)
Dans le cas de mémoire partager ils auront la même adresse virtuelle pour le même segment réel, mais pour les locks et compagnies il faudra quand même que le système fasse le map réel/virtuel pour chaque processus (en d'autres termes chaque lock engendrera un appel au mmu). Ce qui n'est pas le cas pour les threads.
Meme remarque que pbpg: boucler sur un spinlock fait rarement gagner du CPU par rapport à un appel système bloquant. Et si oui, un changement d'algo devrait être sérieusement envisagé.
a - moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
si tu veux passer par des messages intra processus pour signaler un lock c'est possible itou
b - si tu as besoin d'un vrai mutex bien agressif entre deux processus qui ne se connaissent pas forcéement (exemple : wrapper sur une ressource comme xfree ou driect fb) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Là il faut que tu m'expliques quels sont ces locks que le sytème a à gérer quand un père a des shm et fait un fork !
moi j'ai pas parlé de spinlock. Si tu veux faire tes locks en mode wait (sans retry continu) c'ets possible aussi à l'intérieur d'un thread
Si tu veux de l'attente pasive, tu utilises forcément un syscall avec passage en kernelspace. Et donc tout ton argument d'économiser un syscall tombe.
) tu vas être obligé de faire de gérer des files d'attentes ou de faire des mutex avec retry et donc consommer du CPU aussi (et en plus tu auras les appels systèmes par dessus)
Je ne vois pas en quoi une thread pourrait faire de l'attente active qui ne soit pas possible avec shm. Ni en quoi une thread pourrait faire de l'attente passive sans passer par un syscall !
[^] # Re: vs POSIX shared memory, read-only
Posté par galactikboulay . Évalué à 2.
Je crois surtout que tu n'as rien compris aux spinlocks.
Un spinlock, c'est fait pour protéger une section critique extrêmement courte.
Quand il n'y a pas de contention (en principe la plupart du temps),
le spinlock ne boucle pas: un spinlock consiste juste en une
instruction "test&set" du processeur et une boucle si le test échoue.
Quand le test n'échoue pas et que le lock peut être pris, il n'y a pas
de boucle et pas de CPU consommé.
A ton avis, pourquoi les spinlocks sont autant utilisés dans le noyau
Linux ?
Après, comparer un spinlock à un appel système, c'est n'importe
quoi. Sur Linux / i386, un appel système s'effectue par interruption
(int 0x80). Tu regarderas le nombre de cycles que prend une
instruction de ce genre sur un CPU, associé avec ça à la sauvegarde
du contexte du processus, je te garantis que ton spinlock aura
terminé bien avant.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 2.
Je n'aime pas le terme "protégé ici". Un spinlock ne protège rien, comme tu le dis toi même il fait test&set, mais il faut que ce test&set soit atomique au niveau du cpu sinon c'ets le mur direct.
Génralement un spinlock est utilisé comme test&lock en user space, avec un vrai lock des familles directement dérrière de test et test&lock qui est atomique.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Le noyau ne ferait certainement pas de spinlock si c'était le mur direct ! Et de toutes façons le noyau peu difficilement faire un appel système pour se synchroniser :)
Les processeurs puissants actuels sont tous capables de faire des spinlocks atomiques.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 2.
D'un autre coté il est pas en user space et risque pas de se faire interrompre par le noyau. Ca aide.
Et de toutes façons le noyau peu difficilement faire un appel système pour se synchroniser :)
Non, mais d'un autre coté il peut faire tout une batterie d'appels matériel, ca aide aussi.
Les processeurs puissants actuels sont tous capables de faire des spinlocks atomiques.
Là il va falloir que tu me donne ta définition de spinlock. Parceque j'ai du mal à comprendre ta phrase et je n'arrive même pas à emettre d'hypothèses sur son sens.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Les SMP peuvent gêner les locks non atomiques autant qu'un appel système !
Là il va falloir que tu me donne ta définition de spinlock
Je crois que c'est la même que celle de Galactic B:
Un spinlock consiste à boucler sur une instruction "test&set" atomique du processeur.
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 2.
Euh.... Un lock non atomique ? Heureusement que la pose des locks est toujours atomique, c'est bien assez le bordel comme çà. Si en plus il fallait utiliser des sous-locks pour prélocker les locks on s'en sortirait plus. Ensuite le kernel n'est interruptible que si il le veut bien (même par un autre bout de kernel tournant sur un des CPUs d'à coté). Et à partir du moment ou un CPU fait un check sur une ressource tous les autres CPUs sont automatiquement blockés pour cette ressource, voir pour cette plage de ressources (2 CPUs différents ne peuvent pas accéder une même banque mémoire en même temps). Donc si le kernel veut faire une série de tests complexes (ie non atomiques) sur une ressource précise et faire le lock seulement si les tests sont validés, c'est pas le CPU d'à coté qui va l'en empécher (et ça tombe bien d'ailleurs, parceque sinon sur les multis-pros de type "tiens ? et si on mettait 20 000 pentium pro à la queue leu leu" ca serait drole). Le problème viendra plutôt d'une interruption matérielle.
Un spinlock consiste à boucler sur une instruction "test&set" atomique du processeur.
Nous sommes d'accord sur la définition, maintenant j'aimerais juste que tu m'expliques comment cette boucle peut être atomique.
Si c'est l'instruction "test&set" qui doit être atomique, sache qe tous les processeurs depuis la préhistoire de l'informatique savent faire des opérations atomiques de type "test&set".
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Test_and_set atomique signifie il y a 1. "avant" et 2. "après", mais pas "pendant":
1. Avant: Si le process est suspendu par le noyau avant que le test_and_set atomique réussisse, il n'y a pas de problème puisque la ressource (le lock) n'est pas possédé.
2. Après un test and set réussi, le lock est pris ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne:
"It is typically used to implement the contended case of a lock in shared memory"
"When a futex operation did not finish uncontended in userspace, a call needs to be made to the kernel to arbitrate. Arbitration can either mean putting the calling process to sleep or, conversely, waking a waiting process"
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 2.
C'est marrant c'est exactement la question que je me posais. Donc ton spinlock atomique sur processeurs récents on est d'accord tous les deux pour dire que ça ne veux rien dire (vu que spinlock => boucle)
2. Après un test and set réussi, le lock est pris !
J'ai l'impression que tu te perds. dans l'ordre :
a) un spinlock n'est pas un lock. C'est un retry constant d'une opération sur une ressource. Dès que l'opération passe , le spinlock se termine, la ressources peut être lue/écrite/modifiée sans jamais avoir été lockée. Même si le test qui permet de savoir que le spinlock c'est terminé se déroule plus tard.
b) On peut utiliser un spinlock pour faire comme opération atomique un lock. Mais autant faire l'opération de lock directement et récupérer le résultat (erreur ou OK). Ca revient exactement au même vu que la pose d'un lock est une opération atomique.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
2. Après un test and set réussi, le lock est pris !
Comme tu es très pointilleux sur les mots, je corrige le point "2."
2. Après un test and set réussi, la variable est modifiée ! Donc il n'y a aucun risque qu'un autre process puisse posséder la resssource en même temps. Cet autre process devra faire de l'attente active (par définition d'un spin-lock) s'il veut posséder la ressource. S'il veut être sûr de ne pas faire d'attente active, alors il doit utiliser un syscall semaphore au lieu du spinlock.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . Évalué à 2.
Désolé d'être pointilleux, mais entre la boucle atomique, le spinlock qui locke et les futex au final, j'étais un peu perdu.
Mais là ca va mieux.
Mais dans le cas de Linux, les futex permettent d'éviter ce dilemne sans utiliser un sous-scheduler interne
Ce qui permet de passer à la question piège : a ton avis les futex, c'est un lock qui génère un sigsev si tu passes outre ou un lock informatif façon NPTL ? (Hint : la NPTL utilise massivemetn les futex)
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
Qui a parlé de lock qui génère un sigsegv ?
J'ai surtout parlé de variables privées qui génèrent des sigsegv dans les cas des process concurents utilisant shm. Toutes les variables qui ne sont pas dans le shm, pour être précis, sont donc privées et protégées par sigsegv.
Quasiment tous les locks de synchronisation pour accéder à des zones mémoires partagées dépendent de la bonne volonté des parties en présence, puisque si la ressource est vraiment partagée, les parties peuvent y accéder sans faire appel à une fonction de lock, et donc passer outre cette fonction de lock. La seule exception notable étant les locks des fichiers, que personne n'est obligé d'utiliser. Et quand je parle de shm, j'en parle au sens large, pas seulement au sens de shm_open qui associe les shm à des fichiers. Il y a aussi shmget et mmap(MAP_ANONYMOUS) qui n'obligent pas à se servir de fichiers.
Bref:
Les futex sont utilisables pour les shm sans compromettre les variables privées des process (évidemment !) . Ils ont d'ailleurs été pensés pour ça:
"while the addresses for the same memory in separate processes may not be equal, the kernel maps them internally so the same memory mapped in differ-
ent locations will correspond for futex calls."
[^] # Re: vs POSIX shared memory, read-only
Posté par NOULARD Eric (site web personnel) . Évalué à 1.
protéger l'accès à 'un bout de mémoire' avec
l'appel système [POSIX de surcroît]:
int mprotect(const void *addr, size_t *len, int prot);
Donc si plusieurs threads veulent se protéger des autres alors
mprotect e READ-ONLY de ce qui doit l'être.
Ce qui est largement similaire à un shmget/shmat avec READ-ONLY.
y' a des restriction sur la taille et l'alignement des zones
'mprotect-able' justement car c'est le HW (MMU) qui assure la protection.
[^] # Re: vs POSIX shared memory, read-only
Posté par free2.org . Évalué à 2.
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.
[^] # Re: vs POSIX shared memory, read-only
Posté par galactikboulay . Évalué à 2.
du processus.
Les threads se partagent exactement le même espace d'adressage
(logique, c'est le principe même). Concrètement, au niveau de la MMU
ça veut dire mêmes tables de pages ("mêmes" dans le sens
"partagées", pas recopiées entre threads).
Vu que les tables de pages sont les mêmes, un appel à mprotect()
qui modifie justement ces tables de pages impliquera que l'action
impactera tous les threads.
Pour info, sur les CPU i386, un changement de tâche se fait à l'aide
d'un changement de TSS (Task State Segment). Dans ce TSS, on
trouve le registre CR3 qui indique l'adresse du catalogue de pages
(lui même pointant vers les tables de pages). Pour toutes les threads
d'un même processus, le registre CR3 est le même.
[^] # threads schédulées par l'OS avec page table légèrement modifiée
Posté par free2.org . Évalué à 2.
Ceci est surtout obligatoire dans le cas où la libpthread organise un sous-scheduler pour les threads à l'intérieur d'un process (changements de threads qui peuvent donc se faire sans passer par l'OS, donc sans la possibilité pour l'OS de modifier la page table).
[^] # Re: vs POSIX shared memory
Posté par reno . Évalué à 3.
Je ne vois pas le rapport..
Tu peux utiliser de la shared memory sur des systèmes sans swap et les threads utilisent de la même manière le gestionnaire de mémoire virtuelle que les processus alors..
Pour le besoin de synchronisation, il est a mon avis rigoureusement identique entre des processus communiquants par mémoire partagée et des threads..
# Tite question par rapport au message précédent
Posté par snurpsss . Évalué à 3.
Merci
[^] # Re: Tite question par rapport au message précédent
Posté par Jerome Herman . Évalué à 10.
On va dire (rapidement) qu'il existe trois grandes entités.
-Le fork.
-Le clone.
-Le thread.
Un fork continue l'execution sur deux processus distinct, chacun ayant sa copie de ce qui a été fait avant le fork et ses instructions sur ce qu'il faut faire après. Exactement comme deux bonhommes qui ont marché main dans la main pendant un moment et dont un décide d'aller à droite et l'autre à gauche. Ce qui affecte un des deux bonhommes n'a aucun effet sur l'autre. La copie des variables et de l'état d'execution est complète.
Un clone est très semblable à un fork, sauf que les deux processus ainsi créés gardent ennormément de choses en commun. La plupart des variables restent dans un pool partagé par les deux processus. Pour reprendre l'exemple de nos deux bonhommes, c'ets un peu comme si bien que séparés ils utilisent tout les deux des chéquiers sur le même compte en banque. Quand un des deux bonhomme utilise un chèque pour payer quelque chose, le compte en banque des deux diminue. Par contre ils font chacun leur bout de chemin séparément. Ici la copie de l'état d'execution est complète (comme pour fork) mais seule les variables nécessaires au fonctionnement d'un processus et au système sont dupliquées. Toutes les autres variables restent communes.
Un thread n'est pas un processus à part entière. Si quoi que ce soit arrive au père, les threads meurent. De plus les threads n'ont pas vraimetn d'environnement d'éxecution propre, ils restent dans l'ombre du processus qui les a créé. Ici nos bonhommes sont des enfants, qui peuvent aller et venir plus ou moins librement mais qui ont interdicion de sortir du jardin et qui doivent rentrer à la maison fréquamment pour dormir/manger/lire un livre etc. Par contre comme ils vivent dans la même maison, ils peuvent tout se partager.
Ici ni les variables ni l'environnement d'execution n'est dupliqué. Les threads jouissent d'une certaine indépendance, mais ce ne sont pas des processus autonomes au sens large.
# Questions
Posté par Lucas . Évalué à 4.
Est-il prévu de faire évoluer l'outil vers un vrai système de monitoring, avec contrôle asynchrone des threads (arrêt d'un thread, execution pas à pas d'un autre, et execution normale d'un 3eme, par exemple), instrumentation d'un thread sans tous les instrumenter, etc ?
Parce que là, si j'ai bien compris, tu instrumentes tout ou rien. Ce qui fait que si tu as 10000 threads, les traces sont pas forcément triviales à analyser. Tu ne peux pas tracer un seul thread sans filtrer la sortie (ce qui, pt de vue overhead, est pas génial) ?
A part ça, ce stage se passe bien ? :-)
[^] # Re: Questions
Posté par lucio . Évalué à 3.
il existe à ma connaissance au moins un produit qui permet de faire du debug sur des programmes multithread de manière efficace:
Etnus totalview
Voici ce qu'on peut faire:
http://www.etnus.com/TotalView/Threads.html(...)
Malheureusement c'est un outil non libre et encore moins gratuit: c'est même cher.
Espérons que la communauté développera un outil permettant les mêmes capacités !
[^] # gdb et algo
Posté par free2.org . Évalué à 3.
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.
# NPTL
Posté par fabb . Évalué à 5.
On peut même dire que linuxthread est très peu utilisé maintenant.
Pour FC4, les entêtes par défaut seront NTPL et GLIBC_2.0 sera marqué comme obsolète.
Sans oublié que la grande majorité des applis qui compilent avec les entêtes linuxthread tournent avec l'implémentation NTPL.
http://www.redhat.com/archives/fedora-devel-list/2005-April/msg0047(...)
[^] # Re: NPTL
Posté par j . Évalué à 3.
D'ailleurs MySQL 4.1 + NPTL sur AMD64 ça plante sans cesse sous la charge, alors que ça fonctionne bien avec linuxthreads.
[^] # Re: NPTL
Posté par reno . Évalué à 2.
Ahem, tu n'exagères pas un peu? Tu sais une majorité de système utilisé en prod sont en 2.4, de la même manière que le noyeau 2.2 a mis lentement a mourrir, le 2.4 va rester utiliser pendant très longtemps: même pour des nouveaux développement..
Je sais RedHat a backporté les NPTL sur 2.4, mais sur 2.4 les third parties utilisent les linuxthread, alors..
# Je la pose, ma question ?
Posté par chx dein . Évalué à 2.
L'exemple parfait de phrase absolument incompréhensible pour le commun des mortels.
Je voudrais juste savoir à quoi servent les linux-headers...
[^] # Re: Je la pose, ma question ?
Posté par erik_lallemand . Évalué à 4.
Rien que le terme "Logiciel libre" n'est pas compréhensible par le commun des mortels, alors forcément, dès qu'on rentre un peu dans les explications, on sait qu'on ne s'adresse pas au même public que "Modes et travaux", ou "L'Equipe"...
N'étant pas programmeur linux, je pense avoir tout de même compris que les threads sont très dépendants des ressources. L'utilisation d'un programme spécial (le débogueur) en parallèle modifie l'utilisation des ressources du systeme, puisqu'il a des besoins lui aussi. En cela, les threads peuvent ne pas agir de la même façon selon que le débogueur est lancé ou non.
Shrodinger avait à peu près le même problème avec le chat de la mère Michèle, pour déterminer si il était vivant ou mort, parce que la boite à chat n'était pas transparente ^_^
[^] # Re: Je la pose, ma question ?
Posté par v_atekor . Évalué à 3.
Il s'agit de trouver les problèmes dans les applications multithreadées, c'est a dire trouver les problèmes qui peuvent apparaitre lorsque plusieurs fonctions _concurentes_ (donc qui s'exécutent en parallèle) discutent ensemble et/ou manipulent les mêmes objets.
Par exemple pour prendre les exemples signalés plus haut, si 2 personnes marchent ensembles (2 threads, faisons simple) et utilisent le même compte en banque et le même vélo (mais attention, pas un tandem!), imaginons encore que l'utilisation du vélo se fait de toute façons pour faire des emplettes, et donc vider le compte. Ajoutons que si le compte est vide avant la fin du mois il y a un gros bug....
il peut y avoir des conflits lors de l'utilisation du vélo...
et des bugs si le compte en banque se vide trop vite
Pour celà un débogueur peut permettre d'intéroger les personnes pour connaitre leurs actions.une par une et savoir qu'est ce qu'il se passe.
Le hic, c'est que pour le cas du vélo, on obtient un changement de dynamique : en interrogeant les personnes on les ralenties, elles font moins d'emplettes, et le compte en banque se vide moins vite : donc en essayant de trouver la source d'un bug, on risque d'empêcher que le bug de se produite.
Au contraire, cet outil se comporte comme des caméras embarquées sur chaqu'une des personnes : on peut analyser, sans changer la dynamique des évènements, et donc analyser _après_ que le bug se soit produit...
C'est plus clair comme ça?
(La phrase est transparente pour développeurs qui sont les utilisateurs de cet outil, très puissant et vraiment pratique.)
[^] # Re: Je la pose, ma question ?
Posté par Raphaël G. (site web personnel) . Évalué à 4.
Y a toujours un ou deux qui fait une connerie, mais tu peut pas les surveiller ( cas du débugger ), car a ce moment là tu change les conditions et ils sont sages...
Les thread c'est un peu pareil, sauf que c'est dans un programme ou les trubillons sont des foctions concurentes, qui se dépasse et font des conneries dans certaines conditions...
Pense a me plusser si ça t'a aidé, parce que certains semblent jouer a qui arrivera a me faire chutter le plus possible...
[^] # Re: Je la pose, ma question ?
Posté par reno . Évalué à 2.
[^] # Re: Je la pose, ma question ?
Posté par briaeros007 . Évalué à 2.
Il a aussi le droit d'etre curieux non?
[^] # linux-kernel-headers
Posté par free2.org . Évalué à 2.
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"
[^] # Re: Je la pose, ma question ?
Posté par reno . Évalué à 2.
Concept plutot difficile a exprimer en une phrase.. et n'ayant pas de traduction correcte en Francais, donc la première chose a faire est d'ouvrir wikipedia et de regarder le chapitre sur thread, mais je ne pense pas que le sujet doit expliquer ce qu'est une thread..
# pas de séparation de privilèges avec des schedulers userspace!
Posté par free2.org . Évalué à 2.
Le résultat de l'exploit d'un overflow dans T1, c'est justement d'en faire un T1 malicieux !
Quand à la séparation des privilèges avec des schedulers internes en userspace qui évitent les changements de contexte, c'est ridicule:
Démonstration par l'absurde. Supposons que ce soit possible.
On a alors les conséquences suivantes:
1. Cela nécessite le stockage de la threadID courante en userspace, pour pouvoir changer cet ID, donc il est modifiable par une thread T1 malicieuse du userspace.
2. Si tu veux protéger l'accès à cet ID par un segfault, alors il y aura passage en kernelspace à chaque scheduling d'une nouvelle tache.
Ce qui contredit l'hypothèse d'origine.
CQFD
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.