Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Besoin d'une précision concernant les mutex
Bonjour,
Je continue d'apprendre le c pour mon plaisir (de retraité).
Je comprends bien le rôle des mutex pour gérer correctement les accès concurentiels à la mémoire. (ou du moins je pense avoir compris)
Ma question : pour les variables qui sont exclusivement lues, le verrou d'exclusion mutuelle est-il nécessaire ?
D'avance merci.
Bonjour,
Si les seuls accès sont en lecture, il n'y a pas besoin de mettre en place un mutex, sauf si l'accès à cette variable "provoque" une mise à jour quelconque.
Typiquement le cas d'un singleton, si l'instanciation se fait au premier appel.
Tatayo.
Bonjour.
Sans en être formellement sûr le mutex, comme tu le précises, permet la mise en concurrence pour l'accès mémoire. L'accès en écriture est bien entendu facilement compréhensible. Pour l'accès en lecture il me semble qu'il n'y a pas de mise en concurrence. Puisque tu ne modifies rien, c'est l'ordinateur qui va naturellement faire attendre les threads pour accéder chacun leur tour à la donnée.
Maintenant que j'ai dit ça, je vais ajouter un petit bémol. Il faut être bien sûr que la donnée lue ne sera pas, voir jamais modifiée après sa création. Ce que je sous-entends c'est que si cette donnée peut être modifiée par un autre thread, alors il faudra utiliser les mutex quelque soit l'accès à la donnée.
Utilisation de Glade avec Gtk+
Code::Blocks et Gtk+ sous Windows
Programmation orientée objet avec Gtk+ v3
- N'oubliez pas de consulter les FAQ Gtk et les cours et tutoriels Gtk
Salut à tous.
Cela dépend de ce que tu fais après ta lecture. Cela sous-entend s'il y a par la suite une écriture ou pas.
Si écriture après lecture alors il faut appliquer une synchronisation et donc bloquer le traitement par un MUTEX.
Durant le MUTEX, les autres accès seront bloqués tant que le MUTEX ne sera pas terminé.
Si pas d'écriture après la lecture alors aucun Mutex n'est obligatoire.
L'exemple classique est celle de la réservation d'une place en avion ou en train.
Début du traitement.
Lecture seule afin de se renseigner sur la disponibilité des réservations.
Pas de Mutex à ce niveau là.
La valeur lue permet au client de faire sa réservation.
On refait une lecture. Trois cas :
a) Pas de blocage.
La lecture nous fournie la même valeur que précédemment.
On fait un blocage par Mutex.
On effectue la mise-à-jour de la réservation.
On libère la ressource.
b) Pas de blocage.
La lecture nous fournie une autre valeur.
Si la réservation est possible
alors On poursuit la réservation.
On fait un Mutex
On effectue la mise-à-jour.
On libère la ressource.
sinon On abandonne le traitement.
Et l'on recommence le traitement.
c) Blocage.
On attend que la ressource se libère.
Et après libération, on recommence le traitement.
Fin du traitement.
Je rappelle que le premier arrivé est le premier servie. Pas de fil d'attente, pas de priorité.
Le blocage par le Mutex doit être le plus court possible afin de ne pas bloquer les autres consultations.
On applique le Mutex à partir du moment où la valeur lue est celle que l'on veut modifier.
Et l'on libère la ressource quand l'écriture est terminée.
Je rappelle que l'on doit sérialiser les accès en écriture au disque.
C'est un problème bien connu dans la gestion des bases de données.
Merci à tous pour la rapidité et la précision.
C'est effectivement comme l'a dit Artemus24 que comparant les accès dans les Bases de Données j'ai supposé que çà pouvait être inutile de poser un verrou pour des données qui sont toujours lues.
Salut à tous !
En fait, il n'est pas tout-à-fait exact de dire qu'une lecture seule peut toujours être dispensée de mutex : ça n'est vrai que si l'on est certain que l'opération en lecture sera toujours atomique. Or, cela va dépendre de plusieurs facteurs.
Le principal facteur est la taille de la donnée à lire : tant que ça reste limité à la taille d'un registre processeur et d'un accès bus, ça passe, mais un simple double (normalisé sur 64 bits donc) exploité sur une machine 32 bits se fera forcément en deux accès bus consécutifs et rien ne garantit que la donnée ne sera pas modifiée par un thread concurrent au même moment. On pourrait même se retrouver avec une moitié de l'ancienne donnée et une moitié de la nouvelle, ce qui donnerait des valeurs incohérentes et difficiles à expliquer.
L'autre facteur est la disponibilité de la donnée : en général, on utilise des API dédiées pour cela mais si par exemple, le processus ayant revendiqué le mutex décide de décharger la page mémoire vers le swap pour en restaurer une autre à sa place, on risque la segfault si l'accès se fait à ce moment précis.
Dans ce dernier cas, c'est au système d'exploitation de gérer ce cas mais précisément, ce sont des choses auxquelles on fait face en permanence lorsque l'on fait de la programmation noyau. La documentation du kernel Linux est remplie d'anecdotes du même genre, où certaines compagnies ont produit un pilote complet pour leur nouveau produit et l'ont soumis pour intégration, mais où il s'est avéré après examen qu'il avait été écrit exclusivement en mono-processus, c'est-à-dire en faisant complètement abstraction des points exposés ici.
Par contre, effectivement, manipuler un mutex ou un sémaphore reste très coûteux. Il n'est donc pas souhaitable de les utiliser systématiquement « pour le principe ». Montrer que l'on peut s'en passer est toujours bénéfique, à condition que la démonstration soit imparable.
Merci pour ce supplément de réponse.
Dans le cas que j'envisage, c'est un tableau qui est calculé en tout début d'exécution et qui ensuite ne sera la cible que de lectures de la part de différents threads. Aucun thread ne modifie aucune valeur du tableau. La lecture pourra être ralentie par d'autres lectures mais jamais le résultat obtenu ne sera affecté (comme une distribution gratuite de bonbons dans la cour d'école, çà peut être ralenti par la cohue mais le résultat pour chaque demandeur sera le même, pour le distributeur la mort par piétinement est probable). L'économie du mutex me semble intéressante dans ce cas précis.
Ah ! Un segfault, tu es sûr ?L'autre facteur est la disponibilité de la donnée : en général, on utilise des API dédiées pour cela mais si par exemple, le processus ayant revendiqué le mutex décide de décharger la page mémoire vers le swap pour en restaurer une autre à sa place, on risque la segfault si l'accès se fait à ce moment précis.
Dans le cas décrit par Luisne, si le tableau est entièrement calculé avant les pthread_create(), puis jamais modifié, réalloué ni libéré pendant que les threads le lisent, alors le mutex est inutile pour ces lectures. Il n’y a pas de data race : plusieurs lectures concurrentes du même objet ne sont pas conflictuelles tant qu’aucune écriture concurrente n’existe.
Je précise pour les pthread_create(), le reste a déjà été dit...
Celui qui trouve sans chercher est celui qui a longtemps cherché sans trouver.(Bachelard)
La connaissance s'acquiert par l'expérience, tout le reste n'est que de l'information.(Einstein)
Non pas vraiment une segfault en effet mais une exception de page et là encore, elle devrait être invisible aux yeux du programme s'il fonctionne en userspace. Mais comme indiqué, ce sont des précautions qu'il faut commencer à prendre quand on travaille au niveau inférieur, et se souvenir qu'un simple accès mémoire en lecture peut avoir des effets de bords importants dans cette situation.Envoyé par fred1599
Oui mais ça c'est une précision faite après mon dernier message justement. Le message original était un peu plus ambigu. On ne savait pas si la question concernait réellement des variables restant immaculées tout au long de leur existence ou si l'on voulait savoir si un thread exclusivement read-only peut se permettre de se passer de mutex s'il n'altère pas son environnement…Dans le cas décrit par Luisne, si le tableau est entièrement calculé avant les pthread_create(), puis jamais modifié, réalloué ni libéré pendant que les threads le lisent, alors le mutex est inutile pour ces lectures. Il n’y a pas de data race : plusieurs lectures concurrentes du même objet ne sont pas conflictuelles tant qu’aucune écriture concurrente n’existe.
Lorsqu'une page mémoire a été déplacée par un swap, le processeur déclenche un défaut de page. Le noyau recharge alors la page en mémoire physique, puis l'instruction est relancée et la lecture reste valide. Tout cela est normalement transparent pour le programme.Ah ! Un segfault, tu es sûr ?
Aucun rapport avec un Segfault qui peut se déclencher quand tu fais un free(tab) et que tu cherches par la suite à lire ce "tab".
Répondre avec citation
Partager