Discussion :

[sone47]

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

[ram-0000]

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).

[sone47]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
void CSend::setMsg(CInfo* aUserMsg)
{
   wxCriticalSectionLocker lock(mLockMsgCycle);
   // ici je copie dans mMessage
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

[ram-0000]

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

[sone47]

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

[ram-0000]

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é.