Discussion :

[MaelstroeM]

Bonjour,

Voila j'ai besoin de mettre en place une application multithread�e qui se lancera et s'arr�tera automatiquement. Pas besoin d'IHM, la console me semble une bonne solution.

Mon application d�marre donc sur une Sub Main, dans celle-ci j'instancie un System.Timers.Timer qui va v�rifier la pr�sence de travail � faire et lancer les Threads (utilisation de d�l�gu�s) pour traiter le travail. Toute les 5 sec le Timer se lance et alimente les Threads, s'il n'y a plus de travail, le Timer ferme l'application (avec un gros "End", si il y a mieu je suis preneur) .

Le pb est : comment "bloquer" l'ex�cution de Sub Main pour ne pas que l'application se ferme ? Dans mon Sub Main, une fois Le timer instanci� et activ� je n'ai plus rien � faire et si je quitte sub Main l'application se ferme.

Actuellement je "bloque" avec un Console.ReadKey, j'aimerais savoir s'il existe mieux / plus propre.

Merci de votre aide !!!

[Bluedeep]

Ben, si ton appli ouvre une console, c'est qu'� priori elle a une interaction utilisateur, donc le Console.ReadKey, ben c'est pas si mal

Si tu n'as pas d'interaction utilisateur, tu n'as pas besoin de console, et tu fais un service, c'est fait pour cela.

En effet, si tu n'as pas besoin d'interaction utilisateur, on ne voit pas bien pourquoi tu devrais logger la machine sur laquelle s'ex�cute l'appli.

[MaelstroeM]

Si je ne bloque pas le programme va quitter sub main donc quitter l'application alors qu'il y a encore des threads de travail actifs.

Autre petite question : les acc�s � Console sont type Thread Safe ? En d'autre therme puis-je faire des Console.WriteLine("Blabla") depuis plusieurs thread sans que cela ne risque de poser de probl�me (Cross Thread Exception o� autre chose de ce genre).


Merci de ta r�ponse rapide

[Bluedeep]

Si je ne bloque pas le programme va quitter sub main donc quitter l'application alors qu'il y a encore des threads de travail actifs.

Ce n'est pas une obligation, tu peux faire une WaitAll sur des ManualResetEvent (ou n'importe quel autre objet de synchro) que tu auras allou� � chaque thread, et tu termines ton programme quand toutes les threads auront signal�s leur Event.

Mais ce que je te disais, c'est que si on met une console, c'est que � priori on veut une interaction utilisteur (ici, le Console.ReadKey).

Si tu ne veux pas d'interaction utilisateur, tu ne mets pas de console, tu mets ton programme en service.

[Pol63]

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
while not un_booleen
  'traitement
  system.threading.thread.sleep(x)
end while

le bool�en te permet de sortir quand tu le mets � true
sleep arrete le thread pendant x ms

[Bluedeep]

le bool�en te permet de sortir quand tu le mets � true
sleep arrete le thread pendant x ms

L'utilisation d'un WaitAll sur un tableau d'EventWaitHandle me semble quand m�me un peu moins bricolo, non ?

[Pol63]

L'utilisation d'un WaitAll sur un tableau d'EventWaitHandle me semble quand m�me un peu moins bricolo, non ?

ca d�pend, dans les deux cas si c'est mal �crit ca d�conne et c'est pas terriblement maintenable

m'enfin ca d�pend de ce qu'il y a � faire avec ...

[Bluedeep]

ca d�pend, dans les deux cas si c'est mal �crit ca d�conne et c'est pas terriblement maintenable...

C'est un fait, mais je ne pars jamais du postulat que les gens codent avec les pieds (dans les faits, il s'av�re souvent que je fais preuve d'un incorrigible optimisme )

[MaelstroeM]

Bon je suis partie sur qq chose de ce genre :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
If args.Length >= 2 AndAlso UCase(args(1)) = "AUTO" Then
                Console.WriteLine("Démarrage en Automatique")
                Action_Start_Timer(False)
            End If
 
 
            While True
 
 
                Select Case CStr(Console.ReadLine()).ToUpper
                    Case "START" : Action_Start_Timer(False)
 
                    Case "FORCE START" : Action_Start_Timer(True)
 
                    Case "STOP" : Action_Stop_Timer()
 
                    Case "CANCEL" : Action_Cancel()
 
                    Case "END" : Action_Cancel() : Exit While
 
                    Case Else : Console.WriteLine("Commande inconnue")
 
                End Select
 
                Thread.Sleep(0)
 
            End While

Qui me permet de g�rer qq commandes simples.
Si dans le Elapsed du timer il ne trouve plus de travail a envoyer il ferme l'application avec un "End", je n'ai rien trouv� de propre pour router l'information de fermeture au Sub_Main.

Mes threads de travail sont g�r� avec des d�l�gu�s (voir exemple Prime Number Calculator dans MSDN) et sont aliment�s par le System.Timers.Timer qui se lance p�riodiquement.

Par contre je suis curieux de voir ton system de "EventWaitHandle", bien que j'ai crois� �a dans MSDN quand je me suis interr�s� au multiThreading je n'ai pas creus� dans ce sens.

Si j'ai bien compris je peux utiliser un EventWaitHandle , dans le Sub_Main j'attends avec WaitOne que le Timer signal via Set() qu'il n'y a plus de travaux et donc que je peux quitter l'application ?

Dans tous les cas je vous remercie pour votre aide.