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.

[code]
        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);
            }
        }
[/code]

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

pourquoi ne pas utiliser un timer ?


Sébastien FERRAND (blog)
Consultant Sénior
[Microsoft Visual C# MVP]

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# 

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

Réponse acceptée !
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

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

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

c'était un peu le cas d'école producteur consommateur décrit dans l'ebook de MorpionMx

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