Faire attendre un thread si la file est vide

Résolu
Signaler
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011
-
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011
-
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

Messages postés
71
Date d'inscription
jeudi 2 octobre 2003
Statut
Membre
Dernière intervention
12 septembre 2013

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
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011

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
Messages postés
4936
Date d'inscription
lundi 17 février 2003
Statut
Membre
Dernière intervention
14 février 2014
38
pourquoi ne pas utiliser un timer ?

Sébastien FERRAND (blog)
Consultant Sénior
[Microsoft Visual C# MVP]
Messages postés
3466
Date d'inscription
lundi 16 octobre 2000
Statut
Membre
Dernière intervention
30 octobre 2008
55
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# 
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011

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
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011

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
Messages postés
71
Date d'inscription
jeudi 2 octobre 2003
Statut
Membre
Dernière intervention
12 septembre 2013

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
Messages postés
71
Date d'inscription
jeudi 2 octobre 2003
Statut
Membre
Dernière intervention
12 septembre 2013

c'était un peu le cas d'école producteur consommateur décrit dans l'ebook de MorpionMx
Messages postés
25
Date d'inscription
samedi 24 mars 2007
Statut
Membre
Dernière intervention
3 février 2011

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