romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDernière intervention 3 février 2011
-
15 juil. 2008 à 12:09
romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDerniè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.
romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDerniè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.
romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDerniè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 ;-)
romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDerniè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
cs_Scooper
Messages postés71Date d'inscriptionjeudi 2 octobre 2003StatutMembreDernière intervention12 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
romain145
Messages postés25Date d'inscriptionsamedi 24 mars 2007StatutMembreDerniè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é