bonjour à tous,
 
pour une application que je souhaite réaliser, je dois faire du multi threading. Pour voir un peu comment ça marche j'ai commencé par créer un thread depuis le thread principal.
Ces deux threads s'envoient des evenements, notamment, lorsque le thread envoie un certain evenement au deuxieme thread, ça incremente une variable.
Ainsi, j'envoie 10 fois le même évènement à la suite et je m'apercois que le thread secondaire rate des évènements. Si je mets une tempo de 10ms, ça fonctionne mieux; mais je souhaiterais ne pas avoir recours aux tempos.  
En fait, j'ai l'impression que si un evenement arrive au deuxieme thread alors qu'il est en train de faire autre chose que le 'waitformultipleobject', il est poubellisé avant d'être traité!!!
 
Ainsi, est-ce que quelqu'un peut me donner un moyen d'envoyer des evenements "en quantité" en etant sûr que le destinataire n'en rate aucun?
 
Merci d'avance.
 

Ouah, sans la moindre ligne de code, tu veux qu'on lise dans une boule de cristal ou quoi ? Se tirer une balle dans le pied avec les threads, c'est très très facile. Montre le code que tu as, je pourrais te dire ce qui merde.
 
Sinon, Mutex (ou CriticalSection sous win) Semaphore, ça te dit quelque chose ? Parce que c'est indispensable en programmtion multi-threadée, ça permet entre autre d'éviter les effets que tu constates.

voici la procedure de la procedure executee par le thread crée :
 
DWORD ProcBlindTimer(LPVOID lpParametre)
{
 //recuperation du pointeur de la classe CBlindTimer
 CBlindTimer* pBlindTimer = (CBlindTimer*) (lpParametre);  
 
 if (pBlindTimer != NULL)
 {
  //envoi de l'evenement EventProcBlindTimerOk
  SetEvent((pBlindTimer->GetHandleEventTab())[8]);
  Sleep(10);
  DWORD ReceivedObject;
  bool boucle = false;
  int icount = 0;
  while (!boucle)
  {
   ReceivedObject = WaitForMultipleObjects(NBR_EVENT, pBlindTimer->GetHandleEventTab(), FALSE, INFINITE);
   switch(ReceivedObject)
   {
   case WAIT_OBJECT_0:  
    {
     boucle = true;
     break;
    }
   case WAIT_OBJECT_0 + 1:
    {
     icount++;
     break;
    }
   default :
    {
     break;
    }
   }
  }
 
  SetEvent(pBlindTimer->GetHandleEventTab()[9]);
  Sleep(10);
 
  //return 0;
 }
 else
 {
  //return -1;
 }
 return 0;
}
 
 
 
Voici la partie du code du thread principal :
 
hThread = ::CreateThread(  
                 NULL,         // default security attributes
                 0,            // default stack size
                 (LPTHREAD_START_ROUTINE) ProcBlindTimer,  
                 pTimer,         // Le tableau d'evenement en parametre
                 0,            // default creation flags
                 &dwThreadAID); // receive thread identifier
 
 
 WaitForSingleObject(m_BlindTimerEventsTab[8], INFINITE);
 
 //evoi de plusieurs event a la suite
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
 
 //Sleep(50);
 SetEvent(m_BlindTimerEventsTab[1]);
   
 //Sleep(50);
 
 SetEvent(m_BlindTimerEventsTab[0]);
 Sleep(10);
 WaitForSingleObject(m_BlindTimerEventsTab[9], INFINITE);
 
 CloseHandle(hThread);
 
 
 
 
le smutex et autres permettent d'acceder à une memoire partagée de manière sûre je crois. Mais à priori ça ne me permettra pas de ne rater aucun message!!
 
PS : le code envoyé est moche, jen convient; il s'agit juste d'un test de com inter thread pour debuter....

 
bah si justement en te permettant de partager de manière exclusive une variable qui va servir de flag pr dire si oui ou non l'event a bien été reçu et faire du signalement enre thread.

Ok lol. T'es plutôt mal barré pour faire du multithread, là.
Une règle de base: tout espace mémoire partagé par deux threads, dont au moins un en écriture exige nécessairement une synchronisation entre les threads.
Allez, lis ça et sois sûr de comprendre complètement l'article avant d'écrire une seule ligne de code nouvelle:
http://www.codeproject.com/KB/thre [...] ation.aspx
http://www.pluralsight.com/article [...] ep0597.htm
http://www.codeproject.com/KB/thre [...] reads.aspx

Ce qui n'est pas explicitement dit dans le premier article (mais ça l'est dans le 2e) est qu'il est d'usage de créer une classe qui encapsule les lock/unlock, ajoute quelques traces de débogage avec la directive de compilation qui va bien, et de l'instancier sur la pile dans la fonction où le mutex/section critique est nécessaire.
Ainsi, pas de soucis en cas de levée d'exception dans la section critique, le lock est délocké automatiquement (de toute façon, les exceptions dans les sections critiques, c'est déconseillé si on veut de la perf).
Et bien évidemment, que tout appel de fonction accédant à la ressource partagée par les threads et ne faisant pas elle-même la synchronisation doit se trouver dans un mutex. Ce qui signifie en pratique que dans le mutex, il vaut mieux mettre le moins de code possible et vérifier le code de toutes les fonctions appelées, que les méthodes appelées sont compatibles multithread. Enfin, dans certains cas, il est bon de vérifier que le mutex est réentrant.