Si tes estimations sont exactes, c'est en effet un scheduler interne performant.
Le plus long est de poser des masques sur les threads pour els signaux. Mais après le role de ce scheduler est très réduit.
Mais faire du sous-scheduling n'est vraiment utile que quand les flux concurents s'échangent en permanence de touts petits bouts de données.
Ou quand on veut une bonne maitrise de la synchro, ou quand on veut un déroulement "dans l'ordre" de certaines fonctions (en temps réel par exemple), ou quand on veut prioritiser dynamiquement un thread par rapport à l'autre sans nicer tout le processus ou quand veut effectuer un maximum de changement entre deux threads dans le time-slice etc.
En attendant que mon reve se réalise, avoir des threads avec des variables privées protégées par sigsegv,
Dans les threads c'est vrai qu'il n'y a pas de variables vraiment pivée, mais si tu protèges une zone mémoire autant que tu le peux, le thread qui passe au travers ne peut pas vraiment prétendre ne pas l'avoir fait exprès (on n'outrepasse pas un writelock par débordement de tableau).
2. Pour les programmes plus gourmands et qui communiquent habituellement par sockets ou pipe, un shm peut nettement améliorer les performances en évitant les recopies userspace/kernelspace.
Tout à fait, les meccanismes de callback peuvent aussi aider grandement.
La séparation des privilèges, qui nécessite la séparation des process, peut aider à avoir bon niveau de sécurité, malgré une concurence massive.
La séparation des privilèges ne nécessite pas forcément la séparation des process. Il existe un autre système d'IPC qui s'apelle les signaux. C'était le système de référence dans Unix devant les sockets et les pipes. On peut parfaitement définir des masques d'interceptions qui assurent que tel signal sera toujours traité par tel thread.
Enfin quand la fiabilité/sécurité est peu importante, mais la consommation CPU grosse (streams vidéos, jeux locaux ou en réseau...) alors faire du multithread sans démonstration, donc obligatoirement buggé vu la complexité pour gérer des threads.
Gérer des threads peut être très simple sur des taches concurentes parallèles, ne serait-ce que parceque je peux régler l'ordre de déroulement de mes threads sans faire de tests via le scheduler PThread. Tache ardue, si ce n'est impossible avec le scheduler standard.
Les threads permettent également de découper le traitement en petits traitements simples de façon très simple, alors que faire la même chose en SHM demande souvent de créer des protocoles de dialogues inter-processus complexes.
Les SMP peuvent gêner les locks non atomiques autant qu'un appel système !
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".
Le noyau ne ferait certainement pas de spinlock si c'était le mur direct !
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.
Ou sinon tu utilises un scheduler coopératif customisé à l'intérieur de ton process, avec consommation de CPU supplémentaire pour gérer ce scheduling interne.
Si on considére que les scheduling scope/domain des pthreads sont un scheduling coopératif customisé, alors oui je customise à fond. Et oui j'ai une sous attribution de time slice qui doit bien consomer une douzaine de cycles CPU en overhead pour prendre la main, redistribuer aux threads, récupérer la main et la rendre.
La lib pthread fourni un excellent scheduler interne et j'avoue m'en servir.
Le principe même du segment de mémoire partagée est de mapper
les mêmes adresses physiques dans des tables de pages
différentes (appartenant à des processus différents).
Je ne susi pas sur que celà soit aussi simple que çà. Il me semble bien que la mmu s'en mèle dans le cadre des segments partagés. Il faudra que je vérifie dans mes bouquins ce soir...
Un spinlock, c'est fait pour protéger une section critique extrêmement courte.
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.
Par exemple, sous Linux, maximum 4096 segments pour le
_système_. Tu vas me dire que sous Linux c'est tunable (ce qui est
vrai), mais c'est pas forcément le cas de tous les Unix.
Euh... de toute façon la mmu x86 ne sait pas gérer plsu de 4096 segments partagés. Tu peux tuner autant que tu veux, tu n'iras pas loin.
Il faut que tu expliques ça à pbpg ! Car son principal argument contre shm c'est qu'on peut pas utiliser le malloc standard :)
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.
C'est toi qui a parlé de l'obligation d'utiliser de syscall pour synchroniser 2 process.
Tout à fait et je le maintiens
Je t'ai juste rappelé que c'est faux: on peut aussi utiliser un spinlock même si c'est rarement plus efficace à cause du bouclage
En user mode, même pas en rêve. Entre deux processus c'est le mur direct.
Et les spinlocks des threads ont exactement les memes inconvénients que ceux de processus partageant leur mémoire.
Pas du tout. Un pthread_spinlock a des inconvennients mais rien de comparable avec un spinlock de processus. Un pthread_spinlock n'est pas un while(1), c'est un event catcher. Ca n'a rien à voir ni en terme de charge ni en terme d'utilisabilité. Avec un pthread_spinlock tu as les retry, le test et le lock qui viennent de façon atomique. Rien que çà ca fait une ennorme différence.
Comme quelqu'un l'a suggéré un peu plus bas, il n'y a aucune différence au niveau OS entre la synchro de processus partageant de la memoire, et la synchro des threads
Le post de fin de thread pose un des résultats de notre discussion comme une évidence. J'ai donc préféré ne pas répondre.
C'est juste les bibliothèques en surcouche qui ont l'air différentes
Non, je t'assure qu'avoir un seul process au lieu de deux fait un différence réelle qui remonte jusqu'au hardware. ce n'est pas juste une illusion maintenue par du logiciel.
Synchorniser deux threads entre eux est un jeu d'enfant en utilisant readlock/writelock.
Dans les 2 cas ont peut choisir de faire de l'attente active (boucler) ou passive (syscall).
Alors dans le cas de processus en user space on en peut pas se contenter de boucler pour faire de l'attente active. Ca ne marche pas (on n'aura jamais un accès au segment atomique) il faut boucler + syscall (en d'autres termes faire un syscall immédiatement après la réalisation de la condition de test pour locker la ressource)
On peut par contre faire de l'attente passive en trhead sans jamais utiliser le moindre syscall grace aux signaux internes. Ca fonctionen comme un signal syscall, sauf que c'ets généré par le processus lui même à destination exclusive de ses trheads. Ca marche très bien.
Il n'y a pas non plus de RMID si utilise mmap dsur plusieurs segments. RMID est une api spécifique à shm.
Je pensais surtout au mappage d'un segment déjà partagé ailleurs via shm.
??? je parlais du travail de gestion de la VM effectué par l'OS, pour toutes les pages, pas seulement celles issues de mmap, qui n'y changent rien.
Dans les pages mmaper, tu as un fs qui tient le segment occupé même si tous les process qui l'attachent crashent ou se ferment les uns après les autres. Ca permet d'avoir une info qui est dépendante d'un fs au lieu d'être liée à des processus. C'est très pratique pour garder une info "sous le coude". mais si tu n'as pas besoin de cette fonctionalité, autant utiliser shm et des call-back pour faire le boulot.
Prenons le cas d'un segment qui sert de buffer d'échange permanent entre 2 process (une sorte de pipe instantané): le syscall_sémaphore est remplaçable par un spinlock stocké en début de shm.
META GNI ???
Pris un à un je comprend les mots de ta phrase, mais ensembles j'ai du mal à saisir. Les spinlocks c'est pour les threads ou quand tu es absolument sur que toutes opérations sur ton segment seront atomique, et faire un lock sur un segment mémoire partagé entre deux processus sans passer par des appels systèmes, je vois pas comment on peut faire.
Qaund à placer le spinlock en début de shm, ca veut dire qu'il y a un while(1) ou équivalent qui tourne en boucle en permanence dans uns des deux process ? Déjà bonjour le CPU et ensuite j'imagine que quand tu reçois uen info tu break ton while pour sortir (vu que tu n'aimes pas les threads je vois pas comment faire autrement). Là tu fais ton petit traitement et tu relances le while j'imagine. Et tu fais comment pour savoir si il y a eu mise à jour ou pas ? Si tu as loupé des données ? Si c'est pas l'info déjà lue la seconde d'avant ?
Tu es obligé de mettre en place tout un protocole non ? Et de faire des tests. mais si tu fais des tests, tes accès au segment ne sont plus atomiques et donc tu n'es pas sur que le segment que tu as testé est le même que celui que tu vas lire....
Bref tu vas te prendre de ses retours de manivelle quelquechose de violent et ua niveau synchro tu vas pas aller loin. La seule façon de coordoner tes actiosn entre les deux threads c'est de passer par des syscall pour prevenir l'autre thread de ce qui se passe.
Une solution possible, mais pas forcément ecconome consiste à passer par des callbacks. Mais là aussi bonjour l'archi à mettre en place.
Deja je crois que tu n'a pas compris que c'est dans la fonction malloc qu'il y a un mutex.
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).
Il n'y a pas de RMID pour mmap.
Si tu n'utilises que mmap sur un segment non.
Et au moment de swapper une zone inutilisée depuis longtemps, il est facile de vérifier si un process utilise encore cette zone.
Si c'est pour shooter le segment à vue quand tout le monde l'a détaché je ne vois pas trop l'intérret de déranger mmap.
Et je ne vois pas ce que les mutex viennent faire là dedans.
Au sens large (mutual exclusion). Peut importe que ce soit en fait un marqueur file system géré par le kernel, ou une gestion mmu pure pour les locks des process ou autre. De toute façon au moindre changement il faudra que tous les process fassent un syscall pour connaitre l'état du segment avant de faire quoique ce soit d'un peu cavalier dedans.
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) 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.
et n'a pas à mettre à jour une struct shm à chaque fork/attachement/detachement.
Si tu utilises RMID si. Ca se fait automatiquement, mais le compteur de référence doit être mis à jour.
Si tu fais des locks, unlocks, mutexs etc. après le attribution du segment il faut aussi mettre à jour RMID et passer par des appels systemes et/ou MMU pour mettre à jour l'état du segment.
Et c'est quoi le problème ? En quoi offrir une option RMID est-elle mauvaise ?
Houlà, attention je n'ai pas dit que c'était mal, loin de là. Au contraire ca me fait une chouette épine hors du pied comparés aux callbacks en pagaille chez win32 (oui parceque moi et la MFC ca fait 4). J'utilise courament les RMID et j'en suis très content.
Seulement quand on soulève le capot il y a pleins de truc sen dessous quif otn les appels systèmes à ta place pour le tracking. C'ets tout ce que je dis.
Quand on est dan sun thread, même si dans le code on a l'impression que tel thread met un lock et que tel autre réserve la mémoire ce n'est pas tout à fait vrai, en fait pour le MMU c'est le processus qui fait le boulot en nommant les locks, les mutexs et autres pour signaler aux différents threads qui fait quoi. Mais ca n'a pas de cohérence au niveau système, et unthread peut parfaitement retirer le lock posé par un autre thread (même si ca n'est pas recommandé du tout). On perd en fiabilité et en protection, mais en gagne en vitesse et en isolation.
En ce qui concerne la libération de la mémoire allouée, on peut soit créer facilement un compteur de références (vu qu'on est dans le même process c'est pas dur de redéscendre l'info aux threads). Soit se la jouer sagouin et libérer les segments quand le process s'arrette (solution tout à fait acceptable dans pas mal de cas, malgré sont coté gruik). Faire un compteur de références sur de la mémoire partagée n'est pas évident (jette un oeuil sur l'implémentation de RMID). Et un segment partagé n'est pas facilement libérable même quand le dernier process qui l'utilise s'arrette (il aurait plutot tendance à survivre et à rester mappable un moment).
Mais il sera libéré de toutes façons dès que tous les processus l'utilisant seront morts !
Je crois que c'est ça que tu n'as pas compris.
C'est parceque la librairie Posix fait le tracking de ressources à ta place. ca ne se fait pas automagiquement. Les infos du RMID sont mise à jour par la lib (et via des appels systèmes encore si ca peut m'éviter de faire un poste supplémentaire plus bas.)
Le fait que toi, developpeur tu n'ais pas à le faire ne veut pas dire que ça n'est pas fait.
Si les segments sont créés par un père, les fils héritent de son mapping automatiquement.
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)
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).
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).
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.
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.
Et si un pointeur mal programmé essaye de modifier ces données, sigsegv.
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.
C'est presque la même chose, mais pas du tout.
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.
Je pense qu'utiliser des processus communiquant via des POSIX shm est aussi efficace que les threads
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.
Alors, sans vouloir vexer personne.
Tout d'abord le support RHEL est loin d'être parfait, mais pour avoir à faire quotidiennement au niveau applicatif autant que système à tout un tas de support je peux dire qu'il est sans problème dans le top ten.
Je ne suis pas un fan de Red Hat du tout, mais c'est quasi obligatoire quand on veut une config Oracle un peu musclé et le support qui va bien dérrière. J'ai eu mon lot de "on ne fait pas" et de "c'est déconseillé" chez Red Hat (notament quand j'ai voulu créer des devices SNMP dédiés). On fait avec en grinçant des dents. On regarde à coté des supports "pro" supposés intervenir en 4h et qui mettent deux semaine à apporter le remplaçant du disque SCSI qui a cramé et on se dit que Red Hat c'est pas si mal.
Clairement j'utilise RHEL en mode serveur pur non graphique, alors le sproblèmes de prise en charge des cartes graphiques me sont passés loin au dessus. Par ocntre quand j'ai complètement réaménagé Udev et une partie du kernel et que je leur ais envoyé la nouvelle config ils ont recertifié pour Oracle en moins d'une semaine (et m'ont demandés très peut de modif dans ma config). Et c'est çà que j'attends personellement du support RHEL.
Debian a perdu des utilisateurs face à Red Hat Entreprise Linux, les gens qui voulaient un support en acier se sont détournés.
Debian a perdu des utilisateurs face à Gentoo, les gens qui voulaient controller les moindres détails de leur distribs se sont détournés.
Debian a perdu des utilisateurs face à FreeBSD. Les gens qui voulaient un système à la pointe niveau réseau se sont détournés.
Debian a perdu des utilisateurs face à slacware. Les gens qui voulaient un bon compromis temps d'install/utilisabitlié se sont détournés.
Les gens Debian perd face à Ubuntu ne représentent qu'une fraction du reste. Ceux qui aujourd'hui utilisent Linux en utilisateur amateur et qui veulent juste faire du openoffice, du net et imprimer leurs documents n'ont pas leur place chez Debian (et les RTFM par paquets de 100 dans leurs forums le rapellent chaque jour à ceux qui oublieraient).
Debian, omnubilé par sa quète d'un graal inatégnable a oublié les deux règles fondamentales du libre :
- release early, release often (distribuez en avance, distribuez souvent)
- given enough eyeball, all bugs are shallow (avec suffisament d'yeux, tous les bugs sont visibles).
Debian a négligé les "petits" utilisateurs, et les petits utilisateurs s'en sont allés. Certes parmis les petits utilisateurs, seulement un sur cent remonte les bugs et seulement un sur cinq cents esaye de les corriger, mais ils sont des milliers.
Debian a pensé pouvoir maintenir à lui seul deux cents architectures, dont certaines sont utilisés par une poignée de personnes au mieux dont certains juste pour jouer. Denian a voulu porter le poinds du monde sur ses épaules, et c'est nobles. Mais c'est orgeuilleux aussi et le poids du monde écrase Debian au fur et à mesure que les bras pour porter se raréfient.
Quand FreeBSD maintien 50 000 paquets, il le fait dans un arbre à part, indépendant de la distribution, pour qu'aucun paquet ne puisse empécher le système d'évoluer.
Quand OpenBSD audite de façon intensive les paquets, il ne le fait que sur un ensemble restreint. De façon a bien dissocier ce qui est important fiable et sécure de ce qui ne l'est pas.
Quand Debian maintien ses paquets, c'est en mode tout ou rien. Et le plus souvent c'ets le rien qui gagne.
J'avoue volontier mon incompétance à me servir correctement et à maintenir une Debian. C'est sur une Debian Woody que j'ai buté le plus, un environnement J2EE pour un serveur Tomcat dont j'ai été incapable d'optimiser le garbage collector pour que le système n'arrive pas à court de mémoire. On a ensuite comparé le prix d'un professionnel Debian capable de faire ce réglage (et éventuellement les suivants) et le prix d'un serveur plus gros qui accéptait plus de 4Go de mémoire facilement. Le serveur était moins cher de 75%, mais Debian Woody était incapable de faire fonctionner les cartes réseaux sans une vingtaine de patchs, certains cassant le driver SCSI au passage. Ce fut donc une Gentoo en SE-Linux qui remplaça la Debian. Ca aurait pu être une RHEL, ou un FreeBSD, ou une Suse Server, mais pas une Debian.
Debian est un bonheur à administrer, mais parfois il y a juste besoin de plus de puissance. Parceque les normes ont changés, parceque la boite a grossi, parcequ'un client important exige un nouveau système, parcequ'on ferait 2000¤ d'éconnomies par mois en utilisant le périph Y au lieu du périph X. Et là Debian ne peut pas, parceque la norme n'est "pas assez" libre, parceque le noyeau maintenu ne passe pas les 8Go de ram, parceque le nouveau système n'a pas été porté sur Alpha-VMS, parceque le périph Y est trop récent.
Alors Debian gicle de l'endroit ou elle est le plus à sa place : sur le serveur d'un admin-sys qui a pas envie de se prendre la tête sur la maintenance post-installation. Ca fait un admin de moins pour remonter les bugs, un admin de moins pour écrire des scripts et chercher des moyens de faire focntionner tel ou tel appli "quand même". Et à coté de ça, un poste "desktop" sous Ubuntu plutôt que sous Debian c'est négligeable.
[^] # Re: scheduler intra-processus, voir plus haut, sécurité/rapidité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: vs POSIX shared memory, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: scheduling intra process, voir plus bas
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. Évalué à 2.
Je dois être mauvais en jeux de piste, j'ai pas trouvé de post postérieur à 23:36...
[^] # Re: vs POSIX shared memory, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: mmap ANONYMOUS n'a aucun surcout
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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.
[^] # Re: vs POSIX shared memory, X, nouvelles threads
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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, X, nouvelles threads
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: mmap ANONYMOUS n'a aucun surcout
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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 n'a pas pas de RMID
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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.
[^] # Re: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: mmap n'a pas pas de RMID
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: le meilleur compromis performances vs sécurité
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: vs POSIX shared memory,pointeurs,RMID,spin
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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.
[^] # Re: vs POSIX shared memory,pointeurs,RMID,spin
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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 Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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, read-only
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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 Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: Tite question par rapport au message précédent
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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.
[^] # Re: vs POSIX shared memory
Posté par Jerome Herman . En réponse à la dépêche PTT : un outil de trace pour la NPTL. É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: Un si joli troll....
Posté par Jerome Herman . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 2.
Tout d'abord le support RHEL est loin d'être parfait, mais pour avoir à faire quotidiennement au niveau applicatif autant que système à tout un tas de support je peux dire qu'il est sans problème dans le top ten.
Je ne suis pas un fan de Red Hat du tout, mais c'est quasi obligatoire quand on veut une config Oracle un peu musclé et le support qui va bien dérrière. J'ai eu mon lot de "on ne fait pas" et de "c'est déconseillé" chez Red Hat (notament quand j'ai voulu créer des devices SNMP dédiés). On fait avec en grinçant des dents. On regarde à coté des supports "pro" supposés intervenir en 4h et qui mettent deux semaine à apporter le remplaçant du disque SCSI qui a cramé et on se dit que Red Hat c'est pas si mal.
Clairement j'utilise RHEL en mode serveur pur non graphique, alors le sproblèmes de prise en charge des cartes graphiques me sont passés loin au dessus. Par ocntre quand j'ai complètement réaménagé Udev et une partie du kernel et que je leur ais envoyé la nouvelle config ils ont recertifié pour Oracle en moins d'une semaine (et m'ont demandés très peut de modif dans ma config). Et c'est çà que j'attends personellement du support RHEL.
# Un si joli troll....
Posté par Jerome Herman . En réponse à la dépêche Ubuntu, un cauchemar pour la Debian ?. Évalué à 10.
Debian a perdu des utilisateurs face à Red Hat Entreprise Linux, les gens qui voulaient un support en acier se sont détournés.
Debian a perdu des utilisateurs face à Gentoo, les gens qui voulaient controller les moindres détails de leur distribs se sont détournés.
Debian a perdu des utilisateurs face à FreeBSD. Les gens qui voulaient un système à la pointe niveau réseau se sont détournés.
Debian a perdu des utilisateurs face à slacware. Les gens qui voulaient un bon compromis temps d'install/utilisabitlié se sont détournés.
Les gens Debian perd face à Ubuntu ne représentent qu'une fraction du reste. Ceux qui aujourd'hui utilisent Linux en utilisateur amateur et qui veulent juste faire du openoffice, du net et imprimer leurs documents n'ont pas leur place chez Debian (et les RTFM par paquets de 100 dans leurs forums le rapellent chaque jour à ceux qui oublieraient).
Debian, omnubilé par sa quète d'un graal inatégnable a oublié les deux règles fondamentales du libre :
- release early, release often (distribuez en avance, distribuez souvent)
- given enough eyeball, all bugs are shallow (avec suffisament d'yeux, tous les bugs sont visibles).
Debian a négligé les "petits" utilisateurs, et les petits utilisateurs s'en sont allés. Certes parmis les petits utilisateurs, seulement un sur cent remonte les bugs et seulement un sur cinq cents esaye de les corriger, mais ils sont des milliers.
Debian a pensé pouvoir maintenir à lui seul deux cents architectures, dont certaines sont utilisés par une poignée de personnes au mieux dont certains juste pour jouer. Denian a voulu porter le poinds du monde sur ses épaules, et c'est nobles. Mais c'est orgeuilleux aussi et le poids du monde écrase Debian au fur et à mesure que les bras pour porter se raréfient.
Quand FreeBSD maintien 50 000 paquets, il le fait dans un arbre à part, indépendant de la distribution, pour qu'aucun paquet ne puisse empécher le système d'évoluer.
Quand OpenBSD audite de façon intensive les paquets, il ne le fait que sur un ensemble restreint. De façon a bien dissocier ce qui est important fiable et sécure de ce qui ne l'est pas.
Quand Debian maintien ses paquets, c'est en mode tout ou rien. Et le plus souvent c'ets le rien qui gagne.
J'avoue volontier mon incompétance à me servir correctement et à maintenir une Debian. C'est sur une Debian Woody que j'ai buté le plus, un environnement J2EE pour un serveur Tomcat dont j'ai été incapable d'optimiser le garbage collector pour que le système n'arrive pas à court de mémoire. On a ensuite comparé le prix d'un professionnel Debian capable de faire ce réglage (et éventuellement les suivants) et le prix d'un serveur plus gros qui accéptait plus de 4Go de mémoire facilement. Le serveur était moins cher de 75%, mais Debian Woody était incapable de faire fonctionner les cartes réseaux sans une vingtaine de patchs, certains cassant le driver SCSI au passage. Ce fut donc une Gentoo en SE-Linux qui remplaça la Debian. Ca aurait pu être une RHEL, ou un FreeBSD, ou une Suse Server, mais pas une Debian.
Debian est un bonheur à administrer, mais parfois il y a juste besoin de plus de puissance. Parceque les normes ont changés, parceque la boite a grossi, parcequ'un client important exige un nouveau système, parcequ'on ferait 2000¤ d'éconnomies par mois en utilisant le périph Y au lieu du périph X. Et là Debian ne peut pas, parceque la norme n'est "pas assez" libre, parceque le noyeau maintenu ne passe pas les 8Go de ram, parceque le nouveau système n'a pas été porté sur Alpha-VMS, parceque le périph Y est trop récent.
Alors Debian gicle de l'endroit ou elle est le plus à sa place : sur le serveur d'un admin-sys qui a pas envie de se prendre la tête sur la maintenance post-installation. Ca fait un admin de moins pour remonter les bugs, un admin de moins pour écrire des scripts et chercher des moyens de faire focntionner tel ou tel appli "quand même". Et à coté de ça, un poste "desktop" sous Ubuntu plutôt que sous Debian c'est négligeable.