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.
[^] # 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.