Rafraichissement de variable

Version imprimable

Bonjour à tous,

est ce que quelqu'un peut m'expliquer pourquoi je ne sors jamais du while dans ce code ?

En fait le break est exécuté seulement si j'utilise la variable p_ok ... je pense qu'il s'agit d'un truc lié au compilateur , non ?

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
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
 
namespace FileWatcher
{
    class MyFileWatcher
    {
        public Boolean p_ok = false;
        FileSystemWatcher fsw = new FileSystemWatcher();
 
        public MyFileWatcher(){
 
            fsw.Path = @"C:\temp";
            fsw.Filter = "*.txt";
            fsw.IncludeSubdirectories = false;
            fsw.Changed += new FileSystemEventHandler(this.fsw_Changed);
            fsw.NotifyFilter = System.IO.NotifyFilters.LastWrite;
        }
 
        public void Run(){
            Console.Out.WriteLine("Go");
            fsw.EnableRaisingEvents = true;
            while (true)
            {
                    if (this.p_ok) {
                    Console.Out.WriteLine("break");
                    break;
                }
            }
 
        }
 
        private void fsw_Changed(object sender, FileSystemEventArgs e){
            this.p_ok = true;
            Console.Out.WriteLine(e.Name + " - " + e.ChangeType + " - ");
        }
    }
}

05/01/2012, 11h52
kheironn
Cette boucle while :
Code:

1 2 3 4 5 6 7 while (true) { if (this.p_ok) { Console.Out.WriteLine("break"); break; } }
?

while true !!! tu ne sortiras jamais sauf si tu atteins un break.
C'est une grave erreur de conception et de codage !
Edit : si tu n'es pas certain d'avoir un break atteignable.

tu as un this.p_ok (un booléen donc) et rien dans la boucle ne vient le modifier !
S'il ne vaux pas true dès le début, tu ne sorts JAMAIS. Tu as une procédure assync pour la changer cette valeur ??? Parce que ton événement n'intervient pas pendant ta boucle qui "lock" le thread d’exécution -> boucle infini, rien ne se passe.
05/01/2012, 11h57
tomlev

Citation:

Envoyé par kheironn

while true !!! tu ne sortiras jamais sauf si tu atteins un break.
C'est une grave erreur de conception et de codage !

Non, c'est très classique; du moment qu'il y a bien des break accessibles. Parfois c'est plus simple à écrire comme ça, surtout si la condition de sortie est complexe (mais en l'occurrence ça n'apporte pas grand chose).

Par contre c'est pas terrible de boucler infiniment sans aucun temps d'attente entre 2 itérations. Il faudrait au moins ajouter un Sleep, ou mieux, utiliser un WaitHandle

Citation:

Envoyé par kheironn

tu as un this.p_ok (un booléen donc) et rien dans la boucle ne vient le modifier !

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.
05/01/2012, 12h17
Gandahar

Citation:

Envoyé par tomlev

Par contre c'est pas terrible de boucler infiniment sans aucun temps d'attente entre 2 itérations. Il faudrait au moins ajouter un Sleep, ou mieux, utiliser un WaitHandle

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

Ok merci pour le waithandle.

Concernant fsw_changed il est bien exécuté car sur la console je vois bien le writeline. Plus étonnant, si dans le while(true) je mets un

Code:

Console.Out.Writeline(this.p_ok);

alors le break; est bien déclenché. (d'où ma remarque lié au compilateur)
05/01/2012, 12h39
Gandahar

C'etait bien lié au compilateur...
En décochant "Optimiser le code" je n'ai plus le problème...
05/01/2012, 13h46
kheironn

Et tu comptes livrer du code désoptimisé ? Tu es sûr que c'est la bonne façon de procéder ? Je ne comprends pas bien le besoin qui t'amène à ce code, mais je m'interroge sur ce dernier.
J'imagine qu'il s'agit ici d'un exemple et que le traitement réel est plus complexe.

Citation:

Envoyé par tomlev

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

J'ai bien vu... Mais je me demande quand il passe dans son événement dans ce sample.
05/01/2012, 14h06
Gandahar

Le besoin est simple : créer un programme batch effectuant une action lors de l'arrivée d'un fichier (*.txt) dans un répertoire donné.

le programme doit être une application console.

Si tu as des suggestions, je suis à l'écoute...

Citation:

Envoyé par tomlev

Il passe à true dans fsw_Changed. Il faut juste s'assurer que les évènements du FileSystemWatcher sont bien déclenchés sur un thread autre que celui qui exécute Run, sinon ça va bloquer bien sûr.

Ben dans mon cas, c'est le même Thread et cela ne bloque pas....

Voici le corps du programme principal :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 using System; using System.Collections.Generic; using System.Linq; using System.Text; using FileWatcher; namespace FileWatcher { class Program { static void Main(string[] args) { MyFileWatcher f = new MyFileWatcher(); f.Run(); } } }

Voilà ce que je suggère :

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
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using System.Threading;
 
namespace FileWatcher
{
    class MyFileWatcher
    {
        private FileSystemWatcher fsw = new FileSystemWatcher();
        private ManualResetEvent _wait;
 
        public MyFileWatcher(){
            _wait = new ManualResetEvent(false);
            fsw.Path = @"C:\temp";
            fsw.Filter = "*.txt";
            fsw.IncludeSubdirectories = false;
            fsw.Changed += new FileSystemEventHandler(this.fsw_Changed);
            fsw.NotifyFilter = System.IO.NotifyFilters.LastWrite;
        }
 
        public void Run(){
            Console.Out.WriteLine("Go");
            fsw.EnableRaisingEvents = true;
            _wait.WaitOne();
            Console.Out.WriteLine("break");
        }
 
        private void fsw_Changed(object sender, FileSystemEventArgs e){
            Console.Out.WriteLine(e.Name + " - " + e.ChangeType + " - ");
            _wait.Set();
        }
    }
}

05/01/2012, 14h10
Gandahar

Citation:

Envoyé par kheironn

J'ai bien vu... Mais je me demande quand il passe dans son événement dans ce sample.

Et bien lorsque je crée ou modifie un fichier *.txt dans le répertoire C:\Temp
05/01/2012, 14h13
tomlev

Citation:

Envoyé par Gandahar

Ben dans mon cas, c'est le même Thread et cela ne bloque pas....

Non, c'est pas le même thread, je viens de faire le test. Tu démarres le FileSystemWatcher sur le thread principal, mais les évènements se déclenchent sur un autre thread.
05/01/2012, 14h13
Gandahar

Citation:

Envoyé par tomlev

Voilà ce que je suggère :

Excellent !!! je ne connaissais pas cette class ManualResestEvent... Je vais regarder cela de plus près.

merci Bp
05/01/2012, 14h14
tomlev

Sinon, si tu tiens à utiliser un flag (ce qui à mon avis n'est pas la bonne approche), déclare le comme volatile, ça devrait régler le problème.
05/01/2012, 14h39
Gandahar

Effectivement c'est volatile qui me manquait dans mon exemple initial

Le mot clé volatile alerte le compilateur que plusieurs threads accéderont à la donnée membre _shouldStop, et par conséquent, qu'il ne doit pas émettre d'hypothèses d'optimisation à propos de l'état de ce membre. Pour plus d'informations, consultez volatile (Référence C#).
05/01/2012, 14h51
tomlev

Mais je maintiens que l'approche avec un ManualResetEvent est plus propre ;)

Avec ta boucle, tu occupes à fond le processeur juste pour vérifier un flag le plus souvent possible ; d'une part ça ne sert à rien (tu n'as pas besoin de vérifier aussi souvent), et d'autre part le ManualResetEvent fait ça beaucoup plus efficacement, sans occuper le processeur avec le thread qui attend.
05/01/2012, 15h59
kheironn

Citation:

Envoyé par tomlev

Mais je maintiens que l'approche avec un ManualResetEvent est plus propre ;)

Avec ta boucle, tu occupes à fond le processeur juste pour vérifier un flag le plus souvent possible ; d'une part ça ne sert à rien (tu n'as pas besoin de vérifier aussi souvent), et d'autre part le ManualResetEvent fait ça beaucoup plus efficacement, sans occuper le processeur avec le thread qui attend.

J'ai lu quelque part (mais pas retrouvé où) que faire des boucles "d'attente" était un très mauvaise pratique. Il était dit, dans ce même article, qu'il valait mieux faire des événements qui permettaient d'avancer.
Ma lecture est un peu ancienne et je ne me souviens que vaguement ce qui y était dit... dommage !

Si je retrouve cette référence, je colle le lien.