EXÉCUTION D'UN THREAD SANS SURCHARGER LE PROCESSEUR
Lucyberad
Messages postés
414
Date d'inscription
mercredi 16 juin 2004
Statut
Membre
Dernière intervention
26 juillet 2007
-
6 avril 2006 à 20:26
cs_eldim Messages postés 956 Date d'inscription lundi 30 mai 2005 Statut Membre Dernière intervention 21 août 2014 - 7 févr. 2007 à 17:58
cs_eldim Messages postés 956 Date d'inscription lundi 30 mai 2005 Statut Membre Dernière intervention 21 août 2014 - 7 févr. 2007 à 17:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/36913-execution-d-un-thread-sans-surcharger-le-processeur
https://codes-sources.commentcamarche.net/source/36913-execution-d-un-thread-sans-surcharger-le-processeur
7 févr. 2007 à 17:58
7 févr. 2007 à 17:47
oubli de mettre sur ton CV que t'a fait un mail bomber performant avec du multithreading.
4 févr. 2007 à 19:17
Et là j'envoi 2 milliards de mails lol
14 avril 2006 à 14:50
c'est normal faut pas encourager ce genre de chose qui sont néfastent pour les programmeurs et surtout les administrateurs réseau et système (et comme j'ai les 3 métiers en même temps je n'encourage surtout pas ce genre de chose)
14 avril 2006 à 13:54
D'ailleurs j'ai envoyé 10000 mails à un pote j'ai intérêt à vite lui enlevé sinon j'ai à faire à la police ! lol
Redman
13 avril 2006 à 07:45
t'as encore fait des betises avec tes sources...
va falloir faire des choses plus constructives si tu ne veux pas être interdit à chaque fois...
12 avril 2006 à 18:11
Elle sera bientôt améliorée !
12 avril 2006 à 16:43
Bonne continuation !
Redman
12 avril 2006 à 16:27
12 avril 2006 à 10:28
12 avril 2006 à 10:28
donc voila je m'y mettrait aux vacances.
12 avril 2006 à 07:41
pas faux
11 avril 2006 à 18:07
"comme tout joueur de jeux videos" => oui car tout les programmeur motivé sont des joueur (et souvent des bons lol)
11 avril 2006 à 08:54
je lance une instance de class1 qui lance une instance de class2 qui exécute le thread
or si je le fait avec ta façon lorsque le thread sera lancé l'exécution reviendra sur la class1
mais ce que je veux c'est l'exécution reste sur la class2 jusqu'à la fin du thread...
donc ma méthode me convient mieux...
11 avril 2006 à 07:36
merci
(je suis pas du genre à abandonner lol)
(comme tout joueur de jeux videos lol)
10 avril 2006 à 21:04
donc oui le code est bon, mais c'est pas celui que je recommande et de loin pas.
un code ayant le moins de boucle possible ne marchant que quasiement avec des evenements est un bon code.
10 avril 2006 à 11:47
j'aime bien travailler par procedure pour avoir une continuité...
je vai tout de même essayer
sinon l'idée de mon source n'était pas trop mauvaise ?
10 avril 2006 à 11:27
10 avril 2006 à 07:46
Désolé de ne pas avoir répondu plus tôt mais je ne bosse pas souvent le week-end...
si je fais comme ça c'est pour détecter la fin du thread qui est dans une API
Donc, il me faut bien vérifié s'il est terminé ou pas...
9 avril 2006 à 17:38
Voici la procédure avec la sécurité :
Try
If tLoop Is Nothing Then
tLoop = New Threading.Thread(AddressOf Action)
End If
If tLoop.ThreadState = Threading.ThreadState.Stopped Then
tLoop = New Threading.Thread(AddressOf Action)
End If
Catch ex As Exception
MsgBox(ex.ToString, MsgBoxStyle.Exclamation)
End Try
If tLoop.ThreadState = Threading.ThreadState.Running Then
Exit Sub
End If
Try
tLoop.Start()
tLoop.Join() ' Empêche que les threads se dépasse dans le temps
Catch ex As Exception
MsgBox(ex.ToString, MsgBoxStyle.Exclamation)
End Try
Redman
P:S, Pour la composition du tuto, je veux bien participer. Tu peux m'envoyer un MP.
9 avril 2006 à 13:34
donc toi du dit de relancer le thread toute les 1 millisecondes pour effectuer le screenshot... ouais c possible mais fo faire gaffe car un pc mets + de 1ms a prendre un screen et le pc sera super ralenti au bout d'un moment a force d'avoir tout plein de thread qui travaille.
sinon pour la procedure => envoie c'est toujours bon a prendre. et pour le tuto ben je vais reflechir a sa composition ^^
9 avril 2006 à 12:28
En effet ca serait une bonne idée que tu fasses, un tuto.
Veux tu que je montre la procédure pour relancer indéfiniment le thread ?
Redman
9 avril 2006 à 11:54
"Moi j'utilise tout le temps un Thread et rien d'autre et c'est suffisant pour ne pas faire "RAMER" l'ordinateur !" => pareil, il faut en faire plusieur si tu fais plusieur requete en meme temps mais c'est rare comme utilisation...
je devrai faire un tuto sur le multithreading, avec la dose de gens que je corrige la dessus ^^
9 avril 2006 à 10:54
LucyBerad -> Do Loop sert à attendre que le thread ai fini sinon le programme se ferme juste après le démarrage du thread(lorsque on commence par SubMain, inutile lorsque l'objet de démarrage est ue fenêtre)
Eldim -> A quoi sert ThreadStart ??!!
Moi j'utilise tout le temps un Thread et rien d'autre et c'est suffisant pour ne pas faire "RAMER" l'ordinateur !
Redman
7 avril 2006 à 19:27
sinon voila le multithreading n'est pas une tache simple, il est juste que tu as mal pris le prblm et j'essaie de te guider, voila donc ils ne faut pas prendre mal le fait que je te corrige, mais plutot le prendre comme une source d'interessement. (ce qui prouve le long texte precedemment posté)
bonne chance !
7 avril 2006 à 19:21
car voila ma pensée: un thread est un sorte d'"executable" a lui meme qui effectue un bout de code, il y as le thread principal qui fait l'affichage et les ligne de code que on lui donne. On crée un deuxieme thread, ce second thread ne va rien faire en rapport avec le premier et va executeer sa ligne de code, ce second thread (si il est prevu dans ce cas) va effectuer sa tache et rendre un objet au thread principal ou simplement lui faire executer une fonction.
donc voila mon mailaise a propos de isbackground car un thread travaille forcement en arriere plan.
ensuite y'as encore un truc qui me titille, en gros apparament ton code regarde sur le thread secondaire a pas planté, bien mais voila tu rajoute dans ta description "sans surcharger le processeur" or le fait de faire un do loop (une boucle sans fin) est a mon avis beaucoup plus bouffeur de ressource que le second thread qui va etre en "BelowNormal" donc ce que tu cherche a reduire d'un coté tu le compense ensuite de l'autre...
bon donc j'essaie de decoder ton code:
- il permet de lancer un thread mais sans qu'il predomine (d'où le belownormal)
- ensuite tu attend la fin d'un thread avec join. sans arguments join attend la fin du thread, or l'integer (ici 1) determine le temps que le join va attendre la fin du thread secondaire, la tu l'attend 1ms. et ensuite si le join fonctionne pas ben voila le thread principal continue son code
- pour eviter ca tu as mis un do loop pour verifier en permanence la fin du thread sur un laps de 1ms et pour eviter que le do loop bloque le programme durant son executaion, tu as mis Application.DoEvents()
voila, en fait ton thread principal scan si le thread secondaire a fini, mais voila il est largement plus simple que le thread secondaire dise qu'il as fini tout seul comme un grand !
c'est pourquoi ce code est extremement plus propre:
Private Sub Lancer_Thread()
Dim Thread1 As New Threading.Thread(AddressOf Sale_Boulot)
Thread1.Start()
End Sub
Private Sub Sale_Boulot()
'ici on mets le code que le thread secondaire doit effectuer
Dim UneVariable as String = "Je suis une variable"
Me.Invoke(New Evenement(AddressOf Fin_Thread), UneVariable)
End Sub
Private Delegate Sub Evenement(ByVal UneVariable As String)
Private Sub Fin_Thread(ByVal UneVariable As String)
'cette fonction la grace a la fonction delegate est lancée sur le thread principal (celui de l'application) et recoi le string UneVariable en cadeau.
MsgBox(UneVariable)
End Sub
7 avril 2006 à 07:45
Le fait de mettre un doevents permet à ton application de se rafraichir donc pas de blocage
Le join permet de libérer les ressources
Le isbackground ben traduit le en français...(arrière plan)
6 avril 2006 à 20:26
explique les lignes: Th.IsBackground = True et Application.DoEvents()
car la je voit pas ce que ca peut faire au thread...