Discussion :

[xilebo]

bonjour,

je suis confronté à un problème. J'ai une tâche exécutée par un thread qui fonctionne de la facon suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
while (1) {
      Sleep(2000); // endormir le thread pendant 2000 ms
     
      mutex.Lock();

      // executer toutes les taches de ma liste s'il y en a
     
      while (GetNextCommand(cmd)) {
          cmd.Execute();         
      }

      mutex.Unlock();      
}

Toutes les 2 secondes, le thread va donc voir s'il y a des tâches a executer dans une liste. Jusque la, tout va bien.

Par contre, il est possible d'ajouter d'autres tâches à effectuer à n'importe quel moment (par exemple lorsqu'on appuie sur un bouton). Le problème est qu'il faudrait que je réveille mon thread sans attendre la fin du Sleep(2000)

Et je n'ai pas trouvé de mécanisme pour faire ca sous windows. En effet, la fonction ResumeThread() fonctionne avec la fonction SuspendThread() qui ne fait qu'incrémenter/décrémenter un compteur de suspension sans notion de temps. Il y a bien la fonction WaitForSingleObject que je peux appeler sur mon handle de thread avec un temps , ce qui revient à faire un Sleep, mais je ne vois pas comment signaler mon thread pour qu'il sorte du WaitForSingleObject.



Merci d'avance pour vos réponses :jap:

[Médinoc]

CreateEvent()
SetEvent()
ResetEvent()

et WaitForSingleObject()

(sans oublier un CloseHandle() quand tu as fini de jouer avec l'Event)

[xilebo]

merci je vais tester ca

[Aurelien.Regat-Barrel]

Tu peux attendre pour plusieurs évènements en même temps avec WaitForMultipleObjects. Mais pas besoin dans ton cas je pense. Il faut te passer du Sleep, avec un Event par exemple comme le suggère Médinoc.
Pour ma part je verrai bien GetNextCommand se comporter comme GetMessage. Elle est bloquante tant qu'il y a rien, et c'est elle en interne qui gère le Mutex, si c'est possible.
Quant à SuspendThread/ResumeThread, il ne faut pas les utiliser.

[xilebo]

Tu peux attendre pour plusieurs évènements en même temps avec WaitForMultipleObjects. Mais pas besoin dans ton cas je pense. Il faut te passer du Sleep, avec un Event par exemple comme le suggère Médinoc.
Pour ma part je verrai bien GetNextCommand se comporter comme GetMessage. Elle est bloquante tant qu'il y a rien, et c'est elle en interne qui gère le Mutex, si c'est possible.
Quant à SuspendThread/ResumeThread, il ne faut pas les utiliser.

le petit souci est que je dois egalement implémenter ca sous linux (mais je ne suis plus dans la bonne section) et comme ce n'est pas tout a fait les memes mécanismes, il faut que j'adapte mon code pour qu'il fonctionne dans les 2 cas.

Cependant , ton idée est bonne (le fait de rendre GetNextMessage bloquante), car le comportement est assez similaire à la boucle d'événement de windows.

Merci des conseils en tout cas

[Aurelien.Regat-Barrel]

Alors je te conseille ne pas utiliser Win32 mais une lib qui encapsule tout ça. Ainsi, le même code compilera sous Linux & Windows (boost, pthread, ACE, Qt, wxWidgets, ...).

[xilebo]

Alors je te conseille ne pas utiliser Win32 mais une lib qui encapsule tout ça. Ainsi, le même code compilera sous Linux & Windows (boost, pthread, ACE, Qt, wxWidgets, ...).

je ne savais pas qu'il y avait une implémentation des pthreads sous windows.

Je vais tenter d'adapter mon code pour les utiliser.

Par contre, dans quelle section du forum dois-je poster pour avoir une réponse à la question que j'ai initialement posée, mais en utilisant cette fois-ci non pas WIN32 mais pthread ?

merci beaucoup

[Aurelien.Regat-Barrel]

C'est surtout un problème d'algo je pense. Pour les pthread, tu peux poser sur le forum Linux quand tu écris ton code Linux. Si c'est au portage Win32, ici ça reste le mieux je pense.
Pour les lib C++, le forum C++ peut convenir.