Faire attendre un thread si la file est vide

Résolu
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011 - 15 juil. 2008 à 12:09
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011 - 19 juil. 2008 à 00:44
Salut,

je souhaite utiliser une fifo pour balancer des données au port série du PC. Afin de balancer les données, j'ai réalisé un Background worker / thread qui ne fera que ça tant qu'il y a des data à transmettre.

        private void port_DataSend()
        {
            byte[] tmp;
            while (true)
            {
                while (serialQueue.Count == 0) ;
                tmp=serialQueue.Dequeue();
                port.Write(tmp , 0, tmp.Length );
                Console.WriteLine("DataSend Sleep");
                Thread.Sleep(500);
            }
        }

9 réponses

cs_Scooper Messages postés 71 Date d'inscription jeudi 2 octobre 2003 Statut Membre Dernière intervention 12 septembre 2013
18 juil. 2008 à 22:12
Salut,

pourquoi dans ton worker thread tu ferait pas un truc du genre avec un WaitHandle :

(pseudo code)

thread principal ou GUI

private Byte[] FBuff;
private WaitHandler FWait;
fonction()
{
// data to transmit
FBuff = XXX.getDataToTransmit();
FWait.Set();

}

bgrWorker1_doSomething(...)
{

while(FWait.Wait())
{
lock(FBuff)
{
Serial.send(FBuff,0,FBuff.Length);
FWait.Reset();
}

}
}

tu comprend le principe ? bon 'utilise plutot cela pour creer une tempo car on peux définir un temps d'attente comme WaitForSingleObject
3
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011
15 juil. 2008 à 12:14
Bon ok, je suis pas encore familier avec ce forum et à priori on peut pas éditer son message une fois posté bref,

mon problème est que le thread bouffe toutes les ressources en attente sur le while (ce qui est logique).
Est-il possible de l'endormir et de ne le réveiller que si la file reçoit un élément ?

Je pensais à un évènement, mais la classe du .NET ne semble pas gérer ça.

merci ;-)
Romain
0
sebmafate Messages postés 4936 Date d'inscription lundi 17 février 2003 Statut Membre Dernière intervention 14 février 2014 37
15 juil. 2008 à 14:39
pourquoi ne pas utiliser un timer ?

Sébastien FERRAND (blog)
Consultant Sénior
[Microsoft Visual C# MVP]
0
MorpionMx Messages postés 3466 Date d'inscription lundi 16 octobre 2000 Statut Membre Dernière intervention 30 octobre 2008 57
15 juil. 2008 à 14:44
Salut,

Je te conseille de suivre ce lien sur le blog de coq, qui conseille un ebook comprenant tout ce qu'il faut savoir sur les Threads
Bonne lecture

Mx
MVP C# 
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011
15 juil. 2008 à 14:57
Salut et merci pour vos réponses :

@seb : non, le coup du timer sera bien trop lent pour ce que j'ai besoin de faire : c'est pas vraiment realtime comme fonctionnement... vu que j'ai besoin de balancer quasiment à la limite de la vitesse du port com, si je prends quelques ms de retard c'est foutu.

La classe Queue du .NET ne permettant pas de faire ça, je vais faire une méthode Enqueue() qui réveillera le thread si celui-ci est endormi.
Lorsque le thread n'aura plus rien à faire il s'endormira; ça me parait pas mal comme principe, z'en pensez ?

@Mx : merci pour le lien, si j'ai besoin d'une info je saurai où aller jeter un coup d'oeil ;-)

@+
Romain
0
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011
18 juil. 2008 à 22:41
Salut et merci,

j'ai bien compris le principe de ce que tu propose et en fait "si j'avais continué" j'aurai plutôt utilisé les contrôles des threads pour l'endormir s'il n'y avait rien à envoyer et le réveiller au moment d'une écriture dans la FIFO.

En réalité, je me suis rendu compte que je me posais un "faux" problème, car le port série fonctionne déjà en FIFO... afin de respecter le protocole, et ce en multi-thread, je n'ai qu'à synchroniser le write du port com et le tour est joué.

merci à tous, soucis "résolu" (bah oui, y'a plus de soucis )
Romain
0
cs_Scooper Messages postés 71 Date d'inscription jeudi 2 octobre 2003 Statut Membre Dernière intervention 12 septembre 2013
18 juil. 2008 à 22:47
j'avais fait une classe avant en c++ CMySerial où le receive était threadé car bloquant mais pour l'envoi normallement c'est géré par windows et il envoi tout de suite donc ton probleme n'en était pas vraiment un sauf si tu comptait transferer X méga par le port série ce qui aurai surement mis du temps je te l'accorde et qui aurait bloqué ta gui
0
cs_Scooper Messages postés 71 Date d'inscription jeudi 2 octobre 2003 Statut Membre Dernière intervention 12 septembre 2013
18 juil. 2008 à 23:00
c'était un peu le cas d'école producteur consommateur décrit dans l'ebook de MorpionMx
0
romain145 Messages postés 25 Date d'inscription samedi 24 mars 2007 Statut Membre Dernière intervention 3 février 2011
19 juil. 2008 à 00:44
wep, je connais

en fait mes émissions se résument à 3octets par trame vers le hardware, le protocole et tout le traitement amont ont été pensés dans ce but afin d'avoir le moins de latence possible entre la commande et la réponse du matériel. Le coup du thread n'aurait donc rien arrangé

@+
Romain
0
Rejoignez-nous