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.