Semaphore/Mutex ou section critique

Bonjour a tous,

Je me pose une question quand a la protection d'un objet dans un thread.
Cet objet est envoyé cycliquement par mon thread P1.
Cet objet peut être mis a jour par un autre thread.

Je dois donc gérer l'accès a cet objet de façon a ne pas avoir de collision entre ma mise a jour et mon envoi.

Seulement je suis un peu perdu sur quoi utiliser,
J'ai pensé au sémaphore, OK.
Pour le mutex si j'ai bien compris cela correspond a un sema a deux états,
Et il y a également les sections critiques,

Du coup j'ai utilisé les sections critiques en mettant un wxCriticalSectionLocker en début de mes deux méthodes de set et de send.
(Il n'y a qu'un seul autre thread qui accede en ecriture, s'il y avait plusieurs thread en ecriture, cela change t il la donne ?)

J'aimerai donc savoir que vaut il mieux utiliser dans un cas comme celui ci ?
Car j'ai parcourus le forum et GG mais au final je suis toujours un peu perdu..

Merci beaucoup d'avance,

Bonne fin de journée

Attention, je ne parle que pour l'environnement Microsoft :

Une grosse différence en Mutex/Semaphore et section critique, c'est que les Mutex/Semaphore sont inter process alors que la section critique est inter thread seulement.

Il n'est pas possible d'avoir une section critique nommée, elle est forcément anonyme et donc elle ne peut s'utiliser que entre 2 threads.

Les Mutex/Semaphore peuvent être nommés et peuvent donc être utilisés en inter process.

De plus, il me semble que le coût d'utilisation d'une section critique est moindre en termes de ressources (CPU/mémoire).

Dans mon cas j'ai un thread P1 qui utilise ma variable pour l'envoi.
L'api de mise a jour permet a un autre thread de la modifier (il n'y a qu'un seul thread qui l'utilise).
Donc ok pour les sections critiques.

Voici un exemple du code:

Une classe CSend lancant un thread via taskExec qui execute cycliquement la methode sendMsg qui envoi mMessage.
Un autre thread peut modifier mMessage via setMsg.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class CSend : { /////////////////////////////////// // Déclarations des membres ///////////////////////////////////   private: CInfo mMessage; wxCriticalSection mLockMsgCycle; /////////////////////////////////// // Déclarations des methodes ///////////////////////////////////   private: int taskExec(void); int sendMsg( void ); protected: public: void setMsg( CInfo *UserMsg );   CSend(); virtual ~CSend(); };

---

Code:

---

1 2 3 4 5 6

void CSend::setMsg(CInfo* aUserMsg) { wxCriticalSectionLocker lock(mLockMsgCycle); // ici je copie dans mMessage }

---

Code:

---

1 2 3 4 5 6

int CSend::sendMsg(void) { wxCriticalSectionLocker lock(mLockMsgCycle); // Ici j'envoie mMessage }

---

La section critique n'est donc utilisée que par 2 threads,
Je ne comprend pas pourquoi si par la suite un troisième thread venait a vouloir modifier mMessage via setMsg, les sections critiques ne fonctionneraient plus.
Edit: Est ce pour mettre une protection dans le cas ou plusieurs thread voudrait simultanément appeler setMsg ? En fait je résonnais uniquement du point de vue setMsg/sendMsg et non "multiples setMsg"/sendMsg
Que dois je utiliser pour anticiper un tel mécanisme ?
Du coup une section critique est un fait un mutex (deux etats) pouvant etre utiliser seulement entre deux threads ?

Merci beaucoup d'avance

Citation:

---

Envoyé par sone47

Du coup une section critique est un fait un mutex (deux etats) pouvant etre utiliser seulement entre deux threads ?

---

Presque : Du coup une section critique est un fait un mutex (deux états) pouvant être utilisée seulement entre deux ou plusieurs threads d'un même process.

J'ai parlé de 2 threads dans ma 1ere réponse mais je sous entendais 2 ou plusieurs, désolé pour l'imprécision :aie:

Merci beaucoup ram-0000 pour tes réponses ici et sur d'autres posts traitant du même sujet, que j'ai parcourus.
J'ai une dernier, question surement idiote j'en suis desolé:
Un thread appartient a un processus, un processus peut posseder plusieurs thread, ok.
Dans l'appli que j'utilise je peux savoir combien de thread sont créés, mais pour les processus dont tu parles, cela équivaut a l'appli ?

Merci d'avance

Un petit exemple volontairement simpliste :

notepad.exe est un fichier binaire sur le disque.

Si tu cliques dessus, tu lances un process P1 (ou une instance de notepad) qui peut posséder plusieurs threads T1, T2, ...

Si tu cliques une 2eme fois sur notepad exe, tu lances un 2eme process P2 qui peut possèder plusieurs threads T'1, T'2, ...

Les thread T1 et T2 peuvent "partager" une section critique
Les thread T'1 et T'2 peuvent "partager" une section critique

mais le thread T1 ne peut partager de section critique avec T'1 et/ou T'2 car il ne sont pas dans le même process. Dans ce cas de figure, il faudra un mutex nommé ou un sémaphore nommé.

Ok, merci c'est bien ce que je supposais,
Y a t il des exceptions, par ex créer plusieurs processus distinct a partir d'un pere ? Bon après ca sort du titre premier donc j'arrêterai, mais juste pour savoir si l'équation "gestion de threads au sein d'une appli = gestion de threads au sein d'un processus" est vrai et donc ne pas me soucier de savoir si plusieurs process dans l'appli..

En tout cas merci beaucoup pour ces infos ram-0000 :ccool:,
Bonne fin journée

2 processus différents (même s'ils sont des instances du même fichier binaire) possèdent 2 espaces mémoire différents. Les espaces mémoires sont différents et protégés. Un process ne peut atteindre l'espace mémoire d'un autre process (sauf cas très très particuliers de debug).

2 threads (ou plus ;)) d'un même processus partagent le même espace mémoire.

C'est pour cela qu'une variable globale (c'est laid) peut être manipulée par tous les thread d'un même processus. Une section critique peut être vue comme une "espèce" de variable globale gérée dans l'espace mémoire utilisateur (sous Windows). Une sémaphore ou un mutex est géré et stocké dans le noyau.

C'est aussi pour cela qu'un mutex ou un sémaphore peut être utilisé entre 2 process différents du moment que l'on puisse identifier le mutex ou le sémaphore (par son nom sous Windows ou un nombre sous Unix) car il est stocké dans le noyau.