équivalent du pthread_cond_wait de POSIX (unix) en visual C++

Bonjour,

Je code un programme sous visual studio avec un thread producteur et un thread consommateur, en passant par une FIFO.
Je voudrais que le consommateur s'endorme quand il voit qu'il n'y a plus rien a faire et que le producteur le réveille quand il rajoute du travail dans la FIFO.

J'ai donc besoin de fonctions équivalentes aux pthread_cond_wait et pthread_cond_signal de POSIX thread (unix) sous visual C++ (j'utilise les threads de System.Threading), mais je n'en ai pas trouvé dans msdn (à part suspend et resume, mais msdn dit qu'ils sont obsolètes et qu'ils vont être supprimés).

Est ce que quelqu'un connaitrait des fonctions pareilles?

Merci d'avance!

Avec les primitives WaitForSingleObject et ReleaseSemaphore me semblerait plus approprié.
-W

Oui, je suis d'accord que finalement, les sémaphores conviendraient mieux, pour une question d'atomicité.
Voici le code de ma FIFO:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40

template<typename T> ref class queue_en_mutex { private: Mutex^ mutex_de_queue;   public: std::queue<T> * queue_std; // car on peut avoir un pointeur vers un objet non managé mais pas un objet non managé dans une classe managé?   queue_en_mutex(){ queue_std = new std::queue<T>; mutex_de_queue = gcnew Mutex; }; ~queue_en_mutex(){};   T pop(){ T res; mutex_de_queue->WaitOne(); res = queue_std->front(); queue_std->pop(); mutex_de_queue->ReleaseMutex(); return res; };   void push(T t){ mutex_de_queue->WaitOne(); queue_std->push(t); mutex_de_queue->ReleaseMutex(); };   bool empty(){ bool res; mutex_de_queue->WaitOne(); res = queue_std->empty(); mutex_de_queue->ReleaseMutex(); return res; }   };

---

Le problème est que le consommateur va faire un empty(), puis un pop(), mais que les deux appels ne formeront pas une instruction atomique. Un scenario "pas de chance" serait donc:
_le consommateur fait un test pour voir si la FIFO est vide avec empty(), qui lui dit qu'elle est vide.
_le producteur ajoute un élément à la FIFO et réveil le consommateur, qui ne s'est pas encore endormi.
_le consommateur s'endort et attend un signal, qui est déjà passé et qui n'arrivera donc jamais.

Je pense que je vais donc plutot utiliser un sémaphore. On fait un release du sémaphore après un push, et un waitone avant le pop. Le consommateur saura qu'il a terminé quand il tombera sur un élément spécial (ex: "travail_terminé") dans la queue.

Cependant, j'ai l'impression que les sémaphores de visual C++ ont forcément une valeur maximum. Est ce que quelqu'un connaitrait un moyen de ne pas avoir de valeur maximun, svp?

Normalement, pour du producteur/consommateur, il faut DEUX sémaphores: Un pour compter les places pleines, un pour compter les places vides.

Quant à leur valeur maximale maximale, je serais étonné qu'elle soit inférieure à INT_MAX...

J'utilise une queue, dans laquelle mon thread producteur met tous les événements que lui envoie flight simulator (il y en a beaucoup par seconde). le thread consommateur analyse ces évènements, ce qui peut prendre du temps. La queue va donc devenir de plus en plus longue, d'autant plus que l'expérience pendant laquelle on récupère les événements peut durer longtemps. La queue n'est pas limitée en taille.

Utiliser INT_MAX donne une certaine sécurité, mais ce serait quand même mieux si il n'y avait pas de borne supérieure. en plus, je serai forcé d'utiliser un deuxième sémaphore pour compter les places restantes et éviter le SemaphoreFullException, ce qui va ralentir un peu plus mon thread :(. D'autre part, si le sémaphore est stoqué dans un int et qu'il n'y a rien de prévu pour le cas où il y ait un overflow, il ne doit pas y avoir de solution.

Personne ne saurait si on peut utiliser ce sémaphore sans borne supérieur?

Lorsque:

Citation:

---

Le problème est que le consommateur va faire un empty(), puis un pop(), mais que les deux appels ne formeront pas une instruction atomique. Un scenario "pas de chance" serait donc:

1. _le consommateur fait un test pour voir si la FIFO est vide avec empty(), qui lui dit qu'elle est vide.
2. _le producteur ajoute un élément à la FIFO et réveil le consommateur, qui ne s'est pas encore endormi.
3. _le consommateur s'endort et attend un signal, qui est déjà passé et qui n'arrivera donc jamais.

---

Je ne vois pas trop comment 2, va pouvoir signaler quoique ce soit au consommateur. Il viendra pooler un peut plus tard la FIFO pour s'apercevoir qu'elle n'est plus vide et faire des pop.
En 3, le signal qu'attend le consommateur est peut être la fin du sleep pour recommencer le test.
- W

Citation:

---

Envoyé par Médinoc

Normalement, pour du producteur/consommateur, il faut DEUX sémaphores: Un pour compter les places pleines, un pour compter les places vides.

Quant à leur valeur maximale maximale, je serais étonné qu'elle soit inférieure à INT_MAX...

---

N'est-ce pas dans le cas ou le nombre de place libre est borné?
-W

Citation:

---

J'utilise une queue, dans laquelle mon thread producteur met tous les événements que lui envoie flight simulator (il y en a beaucoup par seconde). le thread consommateur analyse ces évènements, ce qui peut prendre du temps. La queue va donc devenir de plus en plus longue, d'autant plus que l'expérience pendant laquelle on récupère les événements peut durer longtemps. La queue n'est pas limitée en taille.

---

Vous aurez toujours besoin d'un mutex pour gérer la synchronisation d'accès aux variables.
Le sémaphore pourrait venir par dessus pour compter le nombre d'évènements à traiter: lorsqu'il n'y en a pas, le consommateur attend.

Citation:

---

Utiliser INT_MAX donne une certaine sécurité, mais ce serait quand même mieux si il n'y avait pas de borne supérieure. en plus, je serai forcé d'utiliser un deuxième sémaphore pour compter les places restantes et éviter le SemaphoreFullException, ce qui va ralentir un peu plus mon thread :(. D'autre part, si le sémaphore est stoqué dans un int et qu'il n'y a rien de prévu pour le cas où il y ait un overflow, il ne doit pas y avoir de solution.

---

Si la valeur du sémaphore compte le nombre d'évènements à traiter, vous aurez des soucis de mémoire physique disponible bien avant d'avoir un overflow... et si vous avez une pile d'évènements si importante, il va falloir tellement de temps pour dépiler tout ca que le joueur sera tenté de rebooter

Puisque vous savez qu'il y aura rapidement des évènements à traiter, la vraie question est de savoir s'il est utile de mettre un sémaphore plutôt qu'un mécanisme de pooling de l'état de la queue lorsqu'elle est vide...
=> personnellement, maintenant que je comprend mieux votre soucis ce serait peut être ce que j'essaierai en encapsulant la mécanique d'une facon ou d'une autre au cas ou il serait utile d'en changer.

- W

@ wiztricks: à propos de ton avant dernier post:
dans la citation de moi que tu as utilisé, je parlais du cas où je n'utilise pas de sémaphore, mais des fonctions qui agissent comme pthread_cond_wait (qui endort le thread) de POSIX thread et pthread_cond_signal (qui réveil un thread qui a fait un pthread_cond_wait).
Le consommateur aurait donc fait un pthread_cond_wait en voyant la FIFO vide (à l'étape 3), et le producteur aurait fait un pthread_cond_signal (mais trop tôt, à l'étape 2).

Hmm, ce qu'on attend ou qu'on signale, c'est la condition "file non vide".
Je ne comprends pas pourquoi il serait "fugace".
- W

Si tu utilises une file d'évenements, pourquoi ne pas utiliser celle mise gracieusement à ta disposition par Windows ?

PostThreadMessage(), GetMessage()... Tu n'est pas obligé d'ouvrir une fenêtre pour ça...

@ wiztricks:

Citation:

---

Puisque vous savez qu'il y aura rapidement des évènements à traiter, la vraie question est de savoir s'il est utile de mettre un sémaphore plutôt qu'un mécanisme de pooling de l'état de la queue lorsqu'elle est vide...
=> personnellement, maintenant que je comprend mieux votre soucis ce serait peut être ce que j'essaierai en encapsulant la mécanique d'une facon ou d'une autre au cas ou il serait utile d'en changer.

---

Il y a beaucoup de technique de "pooling", d'après internet. Tu parles de laquelle? Du fait d'avoir une réserve d'objets à utiliser plutôt que de les créer et les détruires à chaque fois?

Je pense qu'il parlait de polling et non pas de pooling.

Sous Windows, je peux confirmer qu'un sémaphore "nombre d'éléments dans la file" est plus rapide, puisqu'un thread reçoit un boost de priorité au moment où il est réveillé par un objet de synchronisation...

@ Médinoc: ok pour le polling.
A propos des sémaphores, est ce que tu les utiliserais, même si il y a une borne supérieure qui n'a pas lieu d'être (puisque la queue n'a pas une taille limite), sachant que cette limite est INT_MAX et que si elle est atteinte, il tellement d'événements que le processus mettra une éternité à terminer de les traiter?

En fait, s'il est garanti que le consommateur ne pourra jamais tout traiter en temps réel, je n'utiliserais même plus une file, ni un buffer bloquant (le coup des deux sémaphores): Je dumperais carrément tout dans un fichier pour le traiter plus tard (typiquement pendant la nuit)...

oui, c'est vrai que c'est plus sur.

Cependant, j'espere que l'appli ne sera pas trop lourde et qu'elle pourra traiter les evenements en temps réel avant de passer des messages, par exemple "attention, vous n'avez pas sorti les trains d'atterissage!".
Dans ce cas, tu utiliserais les sémaphores, même si il y a une borne supérieure qui n'a pas lieu d'être (puisque la queue n'a pas une taille limite), sachant que cette limite est INT_MAX et que si elle est atteinte, il tellement d'événements que le processus mettra une éternité à terminer de les traiter?

Le problème majeur quand une file est pleine, c'est que c'est le thread producteur qui se retrouve bloqué (il attend que le consommateur libère une place).

De plus, je pense que le vrai facteur limitant ne sera pas la valeur limite du sémaphore, mais la taille mémoire disponible (à moins que tu sois en 64 bits)...

Tu veux dire que ma queue (j'utilise la queue de std, qui n'est jamais pleine) sera pleine car je n'aurai plus de place mémoire dans mon processus?

Oui.

Citation:

---

Envoyé par Médinoc

En fait, s'il est garanti que le consommateur ne pourra jamais tout traiter en temps réel, je n'utiliserais même plus une file, ni un buffer bloquant (le coup des deux sémaphores): Je dumperais carrément tout dans un fichier pour le traiter plus tard (typiquement pendant la nuit)...

---

Cela n'améliorera pas les performances :cry:
Ce qu'il faudrait peut être étudier dans ce cas, c'est:

1. augmenter le nombre de consommateurs,
2. compacter les événements

-W