[c# Multithreadé]Gestion de logs

Version imprimable

Bonjour à tous.

Ma question est peut-être assez classique, mais la plupart des réponses me semblent pour le moins "lourdes". En effet, j'ai besoin de tracer les évènements dans un client lourd qui a de "nombreux" threads asynchrones. Or, l'écriture dans un fichier de log unique est problématique, car, de temps en temps, on rencontre des "locks" du même fichier entre threads. De fait, j'ai juste fait ceci

Code:

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
29
30
31
32
33
34
35
36
37
38
39
GestionFichier() { }
 
        //Creation et ecriture du fichier de log
        public void logger(string ligne)
        {
            try
            {
                StringBuilder line = new StringBuilder();
                StreamWriter oStreamWriter;
                while ((oStreamWriter = TryExclusiveOpen(fichierLog)) == null) ;
                line.AppendFormat(@"{0}:{1}", DateTime.Now.ToString(), ligne);
                oStreamWriter.WriteLine(line.ToString());
                oStreamWriter.Close();
            }
            //Gestion de toutes les exceptions
            catch (Exception ex)
            {
                GestionFichier.getInstance().erreur("GestionFichier > logger > Exception > " + ex.Message);
                GestionFichier.getInstance().logger("GestionFichier > logger > Exception > " + ex.Message);
                msg = ex.Message;
                //msg = GestionFichier.getInstance().getMessage("2");
                MessageBox.Show(msg, Constantes.msg_erreur, System.Windows.Forms.MessageBoxButtons.OK);
                System.Environment.Exit(0);
                //fenetreException = new FenetreException(msg, ex);
                //fenetreException.Show();
            }
        }
        private StreamWriter TryExclusiveOpen(String filename)
        {
            try
            {
                StreamWriter oStreamWriter = new StreamWriter(filename, true);
                return oStreamWriter;
            }
            catch
            {
                return null;
            }
        }

Ok, c'est assez crade (pour tester uniquement), mais je cherche à optimiser le tout.
1) Parce que je ne fais pas confiance à une boucle infinie pour faire patienter le thread à l"écriture
2) Parce que je ne suis pas sûr que cela ne peut pas provoquer de bug débile.

Donc:
1° j'ai vu de la gestion de log en threadé sur le net. Est-ce malin/efficace? Me concernant, je suis un peu perplexe de laisser un thread tourner que pour faire quelques écritures de logs.
2° Y a-t-il un moyen plus propre de gérer le lock de fichier, même temporairement?

Toute proposition est bienvenue :)

23/12/2011, 18h40
GuruuMeditation

A tester pour être sûr, mais je pense que log4net est thread safe (il utilise des lock). Sinon tu peux aussi utiliser un lock.(lock code, pas lock fichier)
07/01/2012, 15h22
sinople

Citation:

Or, l'écriture dans un fichier de log unique est problématique, car, de temps en temps, on rencontre des "locks" du même fichier entre threads

C'est un peu la problématique de base du multithreading la gestion du lock pour les ressources qui ne peuvent pas être partagées...

Citation:

j'ai vu de la gestion de log en threadé sur le net. Est-ce malin/efficace? Me concernant, je suis un peu perplexe de laisser un thread tourner que pour faire quelques écritures de logs.

Au final la programmation de type multithread, c'est un peu comme si tu as une usine avec un tas de type qui font chacun une tâche précise au lieu d'avoir un type qui court partout.

Est-ce que c'est plus propre d'avoir à gérer 30 types qui essaye d'écrire sur un tableau et même temps ou d'avoir une personne qui fait que de reporter ce que les 30 autres lui communique.

Un thread qui se tourne les pouces pendant 98% du temps c'est pas un problème en multithread. La gestion du partage des ressources c'est plus le problème du Framework...

Citation:

2° Y a-t-il un moyen plus propre de gérer le lock de fichier, même temporairement?

Sauf erreur il y a la possibilité de mettre un lock sur une variable depuis un thread et de tester le lock (voir d'attendre sa disponibilité) avant d'effectuer l'opération. Ce qui est beaucoup plus propre que d'essayer et de voir si ça plante...

Je te recommande chaudement la lecture suivante:

http://msdn.microsoft.com/en-us/library/c5kehkcz.aspx
07/01/2012, 15h44
DonQuiche

@Magellan94
L'approche classique est de synchroniser l'accès aux méthodes. Concrètement, tu places tout le code de la méthode "logger" dans un bloc "lock" (voir documentation de "lock" sur MSDN). Ce verrouillage va garantir que si un thread A est déjà en train d'exécuter "logger", l'appel de cette méthode par un thread B va mettre B en pause jusqu'à ce que A ait terminé son appel à "logger".

L'autre approche à laquelle tu semblais songer est celle d'un "agent", c'est à dire d'un thread dédié à une activité (ici la gestion du log). Concrètement, un appel à "logger" ne ferait que mettre une ligne dans une file d'attente (et éventuellement réveiller le thread de logging si celui-ci était assoupi) tandis qu'un thread dédié vide régulièrement cette file d'attente pour réaliser l'écriture. Pour ça tu auras besoin de deux composants :
* Une file d'attente thread-safe (il y en a une dans System.Collections.Concurrent) ou une file d'attente privée dont l'accès sera gardé par un verrou (lock).
* Un WaitEventHandle qui permet à un thread de se mettre en sommeil s'il n'a rien à faire (event.WaitOne()) et à un autre thread de le réveiller (event.Set()). Tu gardes le modèle d'une boucle infinie mais ton thread est endormi quand il n'a rien à faire.

Personnellement j'aime beaucoup les agents, j'en mets souvent en place. Toutefois, l'approche traditionnelle est ici simple à mettre en oeuvre et il ne semble pas d'y avoir de raison d'utiliser un agent.
08/01/2012, 20h18
magellan94

Merci pour les deux solutions!:)

J'ai opté, en test, opté pour le "lock" de l'accès (via la fonction suggérée, et grâce à pas mal d'exemples sur le net). De fait, je n'ai pour l'heure rencontré aucun souci, d'autant que le seul souci qui pouvait être rencontré était un accès concurrent par deux threads. J'avais "contourné" en faisant une forme de while qui tentait d'accéder en ouverture/écriture au fichier et à chaque échec, relançait le test. C'était provisoire, crade, et j'ai décidé d'implémenter quelque chose de plus conventionnel et acceptable!

Là, je vais valider par une recette complète le bon fonctionnement pour ma situation (et également valider que j'ai bien utilisé la bonne façon de faire).

Encore une fois, merci pour les renseignements, je ne suis pas encore rôdé aux threads;)

Voilà le code...

Code:

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
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
//Singleton
        public static GestionFichier getInstance()
        {
            lock (_classLock)
            {
                if (null == _Logger)
                {
                    _Logger = new GestionFichier();
                }
            }
            return _Logger;
        }
 
 
		public void logger(string ligne)
		{
            StringBuilder line = new StringBuilder();
            try
			{
				if (_Output==null)
				{
 
                    _Output = new System.IO.StreamWriter(fichierLog, true, System.Text.UnicodeEncoding.Default);
                    line.AppendFormat(@"{0}:{1}", DateTime.Now.ToString(), ligne);
				}
                _Output.WriteLine(line.ToString());
				if (_Output != null)
				{
					_Output.Close(); 
					_Output = null;
				}
			}
			catch(Exception ex)
			{
                string msg = ex.Message;
                MessageBoxTopMost.Show(msg, Constantes.msg_erreur, System.Windows.Forms.MessageBoxButtons.OK);
                System.Environment.Exit(0);
 
			}
		}
 
		public static void closeLog()
		{
			try
			{
				if (_Output != null)
				{
					_Output.Close();
					_Output = null;
				}
			}
			catch(Exception ex)
			{
				Console.WriteLine(ex.Message,new object[0]);
			}
		}

Seulement, je me retrouve parfois avec un pop d'erreur mentionnant que le fichier est en cours d'accès. aurais je loupé quelque chose?

Citation:

Envoyé par magellan94

Seulement, je me retrouve parfois avec un pop d'erreur mentionnant que le fichier est en cours d'accès. aurais je loupé quelque chose?

Oui, tu as :D

C'est dans la méthode logger qu'il convient de faire le lock.

Accessoirement, on ne voit pas l'interêt du scope de niveau classe de ta variable _Output.

ce code là devrait fonctionner mieux :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 public void static logger(string ligne) { StringBuilder line = new StringBuilder(); lock(_classLock) { try { using(StreamWriter output = new System.IO.StreamWriter(fichierLog, true, System.Text.UnicodeEncoding.Default)) { line.AppendFormat(@"{0}:{1}", DateTime.Now.ToString(), ligne); output.WriteLine(line.ToString()); output.Close(); } } catch(Exception ex) { string msg = ex.Message; MessageBoxTopMost.Show(msg, Constantes.msg_erreur, System.Windows.Forms.MessageBoxButtons.OK); System.Environment.Exit(0); } } }
Et tu oublies ton closeLog() qui ne présente pas vraiment d'interêt.

Tu gardes juste la méthode static logger et basta.

10/01/2012, 15h48
magellan94

Ne me dis pas que... j'aurais foutu le lock au mauvais endroit?!
:cry:

C'est en vente libre, les potences et les noeuds coulants?:aie:

Sinon, j'ai vu une autre façon de faire sur le net (oui, je n'attends pas statiquement la solution^^) : usage du Mutex permettant de synchro mes threads en verrouillant l'exécution du traitement de log.

Que dois je choisir? Mutex? lock? Le lock, une fois bien placé, devrait rouler d'après ce que je lis partout... mais le mutex est une bonne ou une mauvaise solution?
10/01/2012, 15h55
Aeronia

En ce qui concerne l'utilisation du Mutex ou du lock, voici un lien qui répondra à ta question :)
10/01/2012, 15h57
Bluedeep

Citation:

Envoyé par magellan94

Que dois je choisir? Mutex? lock? Le lock, une fois bien placé, devrait rouler d'après ce que je lis partout... mais le mutex est une bonne ou une mauvaise solution?

Les Mutex, WauitHandle, Semaphore, etc .... sont parfait quand tu as besoin de faire des syncrho nécessitant des échanges d'information entre thread et/ou des dépendances fonctionnelles. (par exemple, thread n doit attendre que thread n-1 et thread n-2 aient terminées pour utiliser une donnée calculée et repasser la main à thread n+1 après).

Ici, à l'inverse, ton besoin est primitif : ne pas entrer en conflit sur l'écriture, donc un lock suffit.

Dans le cas contraire (attente de libération du log inacceptable pour des raisons de perf. au pouillème de seconde), tu fais un thread de logging auquel tu envoies des messages (ca peut être sous une forme simple, via un objet Queue<T> que ton thread logger va dépiler); mais c'est compliquer les choses pour peu de gain.
10/01/2012, 15h59
magellan94

Mon besoin est hyper simple en effet, et je me fous complètement des performances de log;)

Donc, je vais rester simple et léger: un bon lock des familles et c'est parti.

Je vais également lire le lien histoire d'en savoir plus!

Merci à tous!
10/01/2012, 16h03
DonQuiche

Ton premier lock est bien placé mais il t'en faut aussi un dans "logger" et "closelog".

Concernant les mutexes, ce n'est pas approprié ici. Un mutex ressemble fort à un lock/monitor (lock n'est qu'un sucre syntaxique autour de monitor), les différences étant :
* Un mutex est plus lent (interop)
* Un mutex permet une synchronisation inter-processus.
* Un mutex hérite de WaitHandle, ce qui est utile pour dialoguer avec un code attendant un WaitHandle.
* On peut attendre plusieurs WaitHandle à la fois.

Bref, un mutex n'apporterait rien et ne ferait que compliquer et ralentir ton code.

Citation:

Envoyé par Bluedeep

Les Mutex, WauitHandle, Semaphore, etc .... sont parfait quand tu as besoin de faire des vrais syncrho.

En quoi lock/monitor n'offriraient-ils pas une "vraie synchronisation" ? Je pense que ce n'est qu'un mauvais choix de mots mais ce serait bien de corriger.
10/01/2012, 16h11
Bluedeep

Citation:

Envoyé par DonQuiche

En quoi lock/monitor n'offriraient-ils pas une "vraie synchronisation" ? Je pense que ce n'est qu'un mauvais choix de mots mais ce serait bien de corriger.

Bon, tout à fait, le lock offre une vrai synchro.

J'aurais du formuler en disant "une synchro nécessitant des dépendances fonctionnelles d'exécution et/ou des échanges d'information entre les threads".

Or, clairement ici ce n'est pas le cas.
10/01/2012, 16h32
magellan94

Si je suis bien le raisonnement alors:
- Je dois avoir le lock pour chacune des méthodes techniques qui accèdent à mes fichiers, de sorte à m'assurer qu'il n'y ait aucune ambiguité.
(c'est fait à présent)
- Le mutex n'est utile que pour des cas plus complexes nécessitant des synchros plus maîtrisées, alors que là, je n'ai besoin que de m'assurer un accès verrouillé temporaire à ma ressource.

Je note, je note (et j'apprends ;) )

@Bluedeep
Désolé mais je pense que c'est toujours mal formulé et faux. Tu sembles croire que le Monitor est un spinlock en interne. C'est faux : initialement il commence comme un spinlock mais, s'il échoue, un objet système de synchronisation système est créé. C'est une simple stratégie d'optimisation.

En conséquence, le Monitor n'est en rien moindre que ses contreparties, plus limité ou je ne sais quoi encore. Comparé au mutex, les seules différences se limitent à celles que j'ai citées. Bref, le mutex est à réserver aux scénarios :
* Où l'on veut synchroniser plusieurs processus ou app-domains.
* Où l'on doit impérativement utiliser un WaitHandle pour la compatibilité avec un code existant.
* Où l'on doit parier sur des temps d'attente longs.
* Où l'on doit pouvoir acquérir plusieurs objets de synchronisation simultanément.

EDIT : Je n'avais pas vu la modification que tu avais faîte plus haut (msg10), j'en conclus que j'ai mal interprété le msg13.

@magellan94
Considère que ton objet de synchronisation (celui que tu passes en argument à lock) est là pour protéger l'accès à certaines ressources. A savoir:
* Instance unique.
* Etat interne de cette instance.
* Fichier.

Donc, toute opération qui modifierait ces états, ou qui requiérerait que ces états soient constants durant l'opération, doit être protégée par un bloc "lock".

En l'occurence, "lock" doit donc bien être placé autour de chacune de tes méthodes mais on pourrait imaginer des méthodes qui n'auraient pas cette exigence. Prenons par exemple la création de ton singleton et transformons-là en un bien connu "double-checked locking".
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 public static GestionFichier getInstance() { if (null == _Logger) { lock (_classLock) { if (null == _Logger) { _Logger = new GestionFichier(); } } } return _Logger; }
Ici, seule la partie qui écrit _Logger a été verrouillée. Si _Logger est déjà non-null au début, inutile de verrouiller pour en obtenir la valeur.

Donc, ne part pas du principe que pour rendre une instance thread-safe il suffit d'en verrouiller toutes les méthodes et propriétés. Ça peut ne pas être nécessaire comme ça peut ne pas être suffisant (imagine un compte bancaire avec deux méthodes : getMontant(), retirer(). Chacune d'elles est synchronisée mais si, de l'extérieur, tu vérifie d'abord le montant avant de retirer, il se peut qu'entre les deux appels quelqu'un soit venu altérer le montant. La synchronisation devrait ici être à un niveau plus élevé, groupant les deux appels).

10/01/2012, 21h19
magellan94

Merci pour ces précisions.

Me concernant, je ne pars jamais du principe que verrouiller c'est s'assurer que ça fonctionne correctement. Au contraire d'ailleurs, car l'exemple que tu cites m'est connu d'un point de vue technique... sauf que pour le coup, j'ai géré ce genre de choses par le principe de piles (pas d'opération directe, que des décalées pour bien valider chaque opération).