EXÉCUTION D'UN THREAD SANS SURCHARGER LE PROCESSEUR

Commentaire de Lucyberad le 06/04/2006 20:26:16

ca manque de commentaires ce code...
explique les lignes: Th.IsBackground = True et Application.DoEvents()
car la je voit pas ce que ca peut faire au thread...

Commentaire de Lucyberad le 07/04/2006 19:21:40

ouais ca j'avais compris que traduit ca donnait en arriere plan, mais ca agit comment sur le thread en lui meme, ca lui fait quoi?
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

Commentaire de OneHacker le 09/04/2006 10:54:26

Je suis du même avis de LucyBerad...

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

Commentaire de OneHacker le 09/04/2006 12:28:23

Ben j'utilise par ThreadStart pour le démarrer, je fais "Thread.Start()" tout bête, j'en fait pas plusieurs pour une même requête, je créer la une fonction qui relance le thread lorsque qu'il a finit, et avec cette fonction j'ai fait un prog qui prend 1 screenshot par milliseconde et enregistre l'image dans un dossier, ca marche impec !

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

Commentaire de OneHacker le 09/04/2006 17:38:16

Il a toujours un seul thread qui travaille car j'ai mis une sécurité donc toujours un thread et hyper efficace ! Sans ramer.

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.

Commentaire de Lucyberad le 10/04/2006 11:27:42

pourquoi le thread principal doit verifier que le thread secondaire est terminé alors que avec mon code le thread secondaire dit lui meme au thread principal qu'il as fini, tout marche par evenement et non plus par boucle ce qui est economise BEAUCOUP de la puissance processeur.

Commentaire de Lucyberad le 10/04/2006 21:04:00

ecoute le code fonctionne, il fait le boulot demandé, c'est jsute que c'est pas "officiel" et que c'est pas tres economisateur pour le processeur, c'est tout de meme tres bien de voir que tu t'interresse et que tu ne capitule pas (apres le paté que je t'ai mis lol)
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.

Commentaire de eldim le 11/04/2006 08:54:22

je comprends que ta méthode est plus économe en ressource que la mienne seulement elle pose problème dans ma façon de programmer car :
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...

Commentaire de eldim le 12/04/2006 07:41:04

lol
pas faux

Commentaire de Lucyberad le 12/04/2006 10:28:50

"m'y mettrait aux vacances." => a la rentrée...

Commentaire de OneHacker le 12/04/2006 16:43:37

Je suis pas tout le temps sur internet, je vais mettre une source qui montre l'utilisation de threads mais avant tout ca sera une source MailBomber, je pense qu'elle sera postée dans la journée.

Bonne continuation !

Redman

Commentaire de eldim le 13/04/2006 07:45:37

lol
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...

Commentaire de eldim le 14/04/2006 14:50:41

lol
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)

Commentaire de Lucyberad le 07/02/2007 17:47:49

"Et là j'envoi 2 milliards de mails lol" c fout comme ca revolutionne la programmation...
oubli de mettre sur ton CV que t'a fait un mail bomber performant avec du multithreading.