WEBVTT 00:04.960 --> 00:10.360 Alors les gars, discutons maintenant des contraintes de conception pour l'utilisation de la mémoire partagée en tant qu'IPC. 00:11.680 --> 00:19.480 En d'autres termes, discutons du point de vue de la conception : quand notre application doit-elle utiliser la mémoire partagée comme 00:19.480 --> 00:22.450 technique de communication interprocessus ? 00:22.690 --> 00:28.870 Discutons donc de la recommandation selon laquelle il est bon d'utiliser la mémoire partagée en tant qu'IPC. 00:29.380 --> 00:38.050 L'approche IPC de la mémoire partagée est utilisée dans un scénario où un processus est responsable de la mise à jour de la mémoire partagée. 00:38.260 --> 00:46.660 Le processus responsable de la mise à jour de la mémoire partagée est appelé processus éditeur et les autres processus en cours 00:46.660 --> 00:52.330 d'exécution dans le système sont en fait les lecteurs de la mémoire partagée. 00:52.330 --> 00:58.510 En d'autres termes, ils ne mettent pas à jour la mémoire partagée, mais ils ne font que la lire. 00:58.510 --> 01:01.770 Ils ne lisent que le contenu actualisé de la mémoire partagée. 01:01.780 --> 01:05.150 Ces processus sont donc appelés processus d'abonnement. 01:05.940 --> 01:12.090 Les processus abonnés sont donc ceux qui lisent la mise à jour effectuée par le processus éditeur dans la mémoire 01:12.090 --> 01:12.750 partagée. 01:14.120 --> 01:20.000 Le point suivant que vous devez prendre en considération lorsque vous décidez d'utiliser 01:20.000 --> 01:26.840 ou non la mémoire partagée comme technique IPC est que la fréquence de mise à jour de la mémoire partagée par 01:26.840 --> 01:30.560 le processus de l'éditeur ne doit pas être très élevée. 01:31.670 --> 01:32.300 C'est vrai. 01:32.300 --> 01:38.240 Ainsi, par exemple, le processus de l'éditeur met à jour la mémoire partagée lorsque l'utilisateur configure quelque 01:38.240 --> 01:39.380 chose sur le logiciel. 01:39.620 --> 01:47.780 Ainsi, l'action de l'utilisateur pour configurer quelque chose sur le logiciel est en fait une action qui n'est pas très fréquente en 01:47.780 --> 01:49.970 termes de vitesse des ordinateurs. 01:50.930 --> 01:56.750 Votre processus éditeur ne doit pas mettre à jour le contenu de la mémoire partagée, par exemple, plusieurs milliers 01:56.750 --> 01:58.220 de fois par seconde. 02:00.310 --> 02:07.990 Le critère d'utilisation de la mémoire partagée en tant qu'IPC est donc que le processus éditeur ne doit pas mettre à jour la mémoire 02:07.990 --> 02:10.810 partagée à une fréquence très élevée. 02:12.580 --> 02:19.240 Revenons maintenant au fait qu'il doit y avoir exactement un processus qui doit être responsable de la mise à jour 02:19.240 --> 02:20.820 de la mémoire partagée. 02:20.830 --> 02:24.670 En d'autres termes, il doit y avoir exactement un processus d'édition. 02:24.700 --> 02:26.980 Quelle en est la raison ? 02:27.910 --> 02:30.460 La raison est donc expliquée ici. 02:30.520 --> 02:37.240 Si plusieurs processus tentent de mettre à jour la mémoire partagée en même temps, cela conduit à la droite. 02:37.240 --> 02:38.170 Conflit. 02:38.350 --> 02:45.190 C'est-à-dire que le même morceau de mémoire est écrit par deux processus différents en même temps. 02:45.190 --> 02:51.850 Cela signifie qu'il y a un besoin de synchronisation entre ces processus. 02:52.150 --> 02:59.020 Nous devons donc gérer cette situation en utilisant une synchronisation basée sur l'exclusion mutuelle. 02:59.230 --> 03:07.740 Et chaque fois que vous déployez la synchronisation dans votre logiciel, la synchronisation se fait au détriment de la performance. 03:07.810 --> 03:08.330 Pourquoi ? 03:08.350 --> 03:09.370 Synchronisation, coût. 03:09.370 --> 03:10.210 La performance ? 03:10.240 --> 03:17.840 En effet, nous mettons les threads en veille en plus de leur préemption naturelle par le CPU afin d'empêcher l'accès 03:17.840 --> 03:20.480 simultané à la section critique. 03:21.070 --> 03:21.670 C'est vrai. 03:21.670 --> 03:29.500 Nous mettons donc volontairement les threads en sommeil afin d'empêcher l'accès simultané à la section critique. 03:30.110 --> 03:39.140 Cette action de mise en sommeil des threads réduit donc les performances du logiciel ou, en d'autres termes, la 03:39.140 --> 03:42.230 vitesse d'exécution d'un logiciel. 03:42.260 --> 03:49.160 En résumé, la mémoire partagée en tant qu'IPC est utilisée dans le scénario où il n'y a qu'un seul processus 03:49.160 --> 03:56.390 éditeur et où la fréquence de mise à jour de la mémoire partagée par le processus éditeur n'est pas très élevée. 03:56.420 --> 04:01.640 Voilà donc les deux contraintes que vous devez garder à l'esprit avant de décider d'utiliser ou non 04:01.640 --> 04:05.210 la mémoire partagée comme mécanisme IPC dans votre logiciel. 04:06.170 --> 04:13.040 Maintenant, lorsque le processus de l'éditeur met à jour la mémoire partagée, que se passe-t-il ? 04:13.730 --> 04:17.270 Comment l'abonné serait-il informé de cette mise à jour ? 04:17.360 --> 04:17.990 C'est vrai. 04:17.990 --> 04:23.630 Dans ce diagramme, vous pouvez donc voir que le processus A est un processus éditeur, tandis que les 04:23.630 --> 04:30.080 processus B un et B deux sont des processus abonnés, et que tous ces processus s'exécutent sur le même système. 04:30.200 --> 04:35.360 Nous disposons ensuite d'un morceau de mémoire partagée entre ces trois processus. 04:36.320 --> 04:41.660 Supposons maintenant que le processus de l'éditeur mette à jour la mémoire partagée. 04:43.340 --> 04:49.530 En ce moment, le processus A, qui est un processus éditeur, met à jour la mémoire partagée. 04:49.550 --> 04:52.550 Comment le processus sera-t-il un et le processus sera ? 04:52.580 --> 04:55.280 Deux personnes seraient informées de cette mise à jour. 04:56.280 --> 04:56.930 C'est vrai. 04:56.940 --> 05:01.920 Il devrait y avoir un mécanisme permettant de transmettre les processus B1 et B2. 05:01.920 --> 05:08.550 L'information qu'un processus éditeur vient de mettre à jour la mémoire partagée et que les processus abonnés 05:08.550 --> 05:16.410 doivent également mettre à jour leur structure de données interne en lisant le nouveau contenu de la mémoire partagée. 05:16.680 --> 05:25.650 Pour atteindre cet objectif, après avoir mis à jour la mémoire partagée, le processus d'édition doit envoyer une notification 05:25.650 --> 05:27.960 à tous les abonnés. 05:31.050 --> 05:35.280 qui indique que la mémoire partagée a été mise à jour. 05:35.610 --> 05:41.670 Le processus d'édition doit donc simplement envoyer un très petit message à tous les abonnés. 05:41.670 --> 05:48.930 Ce message signifie que la mémoire partagée a été mise à jour et que les processus abonnés sont censés 05:48.930 --> 05:53.700 lire le nouveau contenu de la mémoire partagée et se mettre à jour. 05:53.880 --> 06:00.750 Ainsi, après avoir reçu cette notification, les abonnés peuvent lire la mémoire partagée mise à jour et mettre à jour leurs structures 06:00.750 --> 06:03.240 de données internes si nécessaire. 06:05.070 --> 06:12.000 La notification générée par l'éditeur et adressée au processus abonné peut 06:12.000 --> 06:19.770 donc être un très petit message, car elle signifie seulement que les processus abonnés 06:19.770 --> 06:25.410 sont censés lire le nouveau contenu de la mémoire partagée. 06:25.860 --> 06:32.610 Cette petite notification peut être envoyée à l'aide d'autres mécanismes IPC tels que Unix, les sockets de domaine ou les files 06:32.610 --> 06:33.990 d'attente de messages. 06:34.650 --> 06:35.190 C'est vrai. 06:35.190 --> 06:42.360 Il s'agit donc d'une petite notification qui pourrait être envoyée à l'aide d'une file d'attente de messages ou de sockets de domaine Unix. 06:43.500 --> 06:44.070 C'est vrai. 06:44.070 --> 06:52.230 C'est donc pour cette raison que l'IPC utilisant la mémoire partagée doit être soutenu ou pris en charge par d'autres types 06:52.230 --> 06:53.640 de mécanismes IPC. 06:54.650 --> 06:55.250 C'est vrai. 06:56.180 --> 07:02.060 Voici donc comment doivent être conçues les applications qui tentent d'utiliser la mémoire partagée. 07:02.090 --> 07:08.270 Le processus éditeur, après avoir mis à jour la mémoire partagée, doit envoyer une notification via d'autres 07:08.270 --> 07:15.500 mécanismes IPC aux processus abonnés pour leur faire savoir que la mémoire partagée a été mise à jour et les processus abonnés 07:15.500 --> 07:22.160 sont alors censés lire le nouveau contenu de la mémoire partagée et se mettre à jour si nécessaire.