Lancer un thread et l'arrêter...
orfait
Membre
Bonjour,
Je viens demander un coup de main (un coup de clavier?) pour une histoire de thread.
Avant de rentrer dans le vif du sujet, j'explique mon problème d'origine.
Je commande une interface USB en lui envoyant des données toutes les 20ms. Si les données à envoyer sont inchangées, on zappe l'envoi pour éviter de saturer l'interface.
J'ai donc créé un logiciel. Pour simplifier l'explication, on va dire que ce logiciel n'a qu'un seul slider et une seule checkbox. Le but est d'envoyer la valeur du slider avec le rafraà®chissement prévu quand la case est cochée.
Mon idée de départ :
Lorsqu'on coche la case, on lance un timer qui se répète et exécute toutes les 20ms un code pour l'envoi des données.
Quand on décoche, on invalide le timer.
Le slider est paramétré pour envoyer de façon continue sa valeur lors de son déplacement.
Tout semble fonctionner dans un premier temps mais en y regardant de plus près, on remarque que pendant le déplacement du slider, le timer est en "pause", donc pour que la valeur passe, il faut relâcher le clic de souris.
>> Il faut donc rendre l'envoi des données "indépendant".
Mon idée a donc été de me tourner vers le multithread.
La nouvelle idée, celle que je vous demande de commenter :
Lorsqu'on coche la case, on met une variable secuthread à 1 et on lance un thread :
Et l'action associée au slider met à jour la variable valeur_slider.
Si on décoche, on met secuthread à 0 et hop, le thread semble se terminer.
Si je teste avec ObjectAlloc : dans NSThread, la valeur de current revient bien à 1.
Conclusion personnelle : ça fonctionne.
Question personnelle : et le priorités sur la variables ? Normalement, avec la fonction sleep, on ne doit pas avoir de deadlock.
Remarque personnelle : merci de ne pas me frapper pour le while(1)... je viens du monde de la prog de microcontrôleur et la chose est courante.
Voilà , dà®tes moi ce que vous en pensez...
Merci
Albin
Je viens demander un coup de main (un coup de clavier?) pour une histoire de thread.
Avant de rentrer dans le vif du sujet, j'explique mon problème d'origine.
Je commande une interface USB en lui envoyant des données toutes les 20ms. Si les données à envoyer sont inchangées, on zappe l'envoi pour éviter de saturer l'interface.
J'ai donc créé un logiciel. Pour simplifier l'explication, on va dire que ce logiciel n'a qu'un seul slider et une seule checkbox. Le but est d'envoyer la valeur du slider avec le rafraà®chissement prévu quand la case est cochée.
Mon idée de départ :
Lorsqu'on coche la case, on lance un timer qui se répète et exécute toutes les 20ms un code pour l'envoi des données.
Quand on décoche, on invalide le timer.
Le slider est paramétré pour envoyer de façon continue sa valeur lors de son déplacement.
Tout semble fonctionner dans un premier temps mais en y regardant de plus près, on remarque que pendant le déplacement du slider, le timer est en "pause", donc pour que la valeur passe, il faut relâcher le clic de souris.
>> Il faut donc rendre l'envoi des données "indépendant".
Mon idée a donc été de me tourner vers le multithread.
La nouvelle idée, celle que je vous demande de commenter :
Lorsqu'on coche la case, on met une variable secuthread à 1 et on lance un thread :
- (void)Refresh<br />{<br />[NSThread detachNewThreadSelector:@selector(senddata:)<br />toTarget:self<br />withObject:nil];<br />}<br /><br />- (void) senddata:(id)object<br />{<br />NSAutoreleasePool * localPool = [[NSAutoreleasePool alloc] init];<br />while (1)<br />{<br />//Traitement et envoi des données<br />envoiusb(valeur_slider);<br />}<br />sleep(0.2);<br />if (secuthread == 0x0) break;<br />}<br />[localPool release];<br />}
Et l'action associée au slider met à jour la variable valeur_slider.
Si on décoche, on met secuthread à 0 et hop, le thread semble se terminer.
Si je teste avec ObjectAlloc : dans NSThread, la valeur de current revient bien à 1.
Conclusion personnelle : ça fonctionne.
Question personnelle : et le priorités sur la variables ? Normalement, avec la fonction sleep, on ne doit pas avoir de deadlock.
Remarque personnelle : merci de ne pas me frapper pour le while(1)... je viens du monde de la prog de microcontrôleur et la chose est courante.
Voilà , dà®tes moi ce que vous en pensez...
Merci
Albin
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
1 - Pourquoi ne pas faire :
?
2 - Avec ce système de "sleep", ça ne sera pas exécuté toutes les 20ms exactement (mais c'est peut-être pas dramatique...)
Comme ça, si ta boucle tourne longtemps, ça va éviter de faire monter la mémoire si il y a des données Autorelease dans la boucle de traitement.
Pour ton slider, tu as bien coché l'option "Continuously send action while sliding"?
while([myCheckBox state]==1) : bonne idée, ça fonctionne et c'est tout bête :P
Pour le "sleep", c'est bon, la précision n'est pas importante.
Et j'ai suivi ton conseil Mala et "Continuously send action while sliding" était bien coché dès le dépard (et pour répondre à ton mail, oui, j'ai utilisé un NSTimer donc pb avec MainThread comme tu dis).
Après test, j'ai remarqué que ça prend 70% de processeur cette boucle... un peu trop je trouve.
Il y a moyen de corriger ça ?
C'est là que c'est le moment d'utiliser Shark pour voir ce qui bouffe le processeur
Après, pour l'interprétation... je veux bien. Mais la résolution là je dois apprendre :why?:
EDIT : VideoScan, c'est le nom de l'appli mais ce n'est ni une camera video, ni un scanner...
Une grosse partie se passe dans le noyau... Pas très clair.
Je vais tenter, je vous tiens au courant.
EDIT : j'ai tenté, aucun changement.
j'avais écrit : sleep(0.02).
Si on regarde juste avant, il y a : - 11.7% nanosleep (libSystem.B.dylib)
Hors, nanosleep est appelé par nsleep (de mémoire). Donc ca veut dire nsleep(20 000 000) !!
En corrigeant par usleep(20 000), la consommation cpu chute à 3%.
Elle est pas belle la vie ?
"sleep" prend un "int" !
Donc pour lui, 0.02 = 0 -> aucune attente, le processeur n'avait aucun repos...
Donc c'était bien ça, mais pas pour la raison que tu pensais :P