Discussion :

[lucky]

Bonjour,
Dans le but d'ameliorer et d'être moins C...
j'ai un prog avec plusieurs Thread (avec priorité haute) ; quand on envoie un évenement d'un thread à un autre peut on garantir que celui ci est traité rapidement ?
Y a t'il une methode pour améliorer cette gestion des évenements en plus de la priorité du thread.
Sur C++ par exemple on a SendMessage et PostMessage qui je crois ne sont pas traités avec la même priorité.
y a t'il quelque chose de comparable ?

[tomlev]

Difficile de te répondre, vu qu'il n'y a pas vraiment de mécanisme générique pour envoyer des évènements d'un thread à l'autre... Qu'est-ce que tu cherches à faire concrètement ? Quel mécanisme utilises-tu actuellement ?

[lucky]

Bonjour,

Ben, j'ai plusieurs Thread (priorité haute) pour acquisition sur une carte entrée de signaux analogiques. Donc le système est assez chargé (sur le µP) et lorsque j'envoie un événement j'ai l'impression (juste impression) que l'exécution parfois ne se fait pas instantanément.
Comme je ne maitrise pas parfaitement, peut être y a t'il des astuces pour avoir des événement prioritaires car ceux de Windows (ex bouton...) ne sont pas très réatif quand le processeur est très chargé. C'est tout.

[tomlev]

lorsque j'envoie un événement

Je ne sais toujours pas ce que tu entends exactement par "envoyer un événement", ni par quel mécanisme tu le fais...
Il n'y pas de mécanisme générique pour envoyer un événement à un thread : un thread, c'est juste un fil d'exécution... Maintenant, si tu parles d'un thread Windows avec une boucle de messages, c'est différent.

Comme je ne maitrise pas parfaitement, peut être y a t'il des astuces pour avoir des événement prioritaires car ceux de Windows (ex bouton...) ne sont pas très réatif quand le processeur est très chargé. C'est tout.

OK, donc tu parles de messages Windows. Bah dans ce cas c'est traité sur le thread UI, donc effectivement ce n'est pas traité en temps réel ; le message ne peut être traité que quand le thread UI est disponible.

Tu fais quoi dans le traitement de ces événements? As-tu vraiment besoin qu'ils soient traités sur le thread UI ?

[lucky]

Non, ce sont des événement que j'ai crée via les delegate etc en bonne te dû forme.

[lucky]

Precision : les evenements, je les récupères dans l'UI effectivement et pour que celle ci les traite plus rapidement j'ai été obligé de mettre l'appli en priorité haute aussi.

[tomlev]

Bah écoute, je comprends toujours pas ce que tu as fait... essaie d'être plus précis, sinon ça va être difficile de t'aider. Pourrais-tu poster un exemple de code ?

[lucky]

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
29
30
31
32
33
34
35
36
37
38
39
40
41
 
public class A
{
        public event InteruptionEventHandler InteruptionForm1;
		...........
 
        private void OnTimePeriodique(object sender, MicroLibrary.MicroTimerEventArgs timerEventArgs) // timer périodique de précision chaque 10ms priorité haute
        {
 
		.... un des traitements
 
		if (conditions)
            // envoie d'une information à la classe Main >> Program.OnInteruptionComptage
            if (InteruptionForm1 != null)
                InteruptionForm1(this, EventArgs.Empty, var /*nbre test*/);
 
		}
 
		........
}
 
 
 
class Appli
{
public Form1()
{
	A a = new A();
 
       a.InteruptionForm1 += OnEventDeTensionVersInterface;
       InitializeComponent();
 
      Thread main = Thread.CurrentThread;
      main.Name = "Main";
      main.Priority = ThreadPriority.Highest  ; // mis aussi en priorité haute pour être assez réactif sinon c'est pire
 
 
	private void OnEventDeTensionVersInterface(object sender, EventArgs e, int index)
        {
           .....
	}

j'ai plusieurs traitements qui tournent chaque 10ms.

[tomlev]

Ah ok, c'est pas ce que j'imaginais. A priori l'événement OnTimePeriodique n'est pas déclenché sur le thread UI (à moins que le composant qui le déclenche s'en occupe, mais si c'est un timer de précision, ça m'étonnerait beaucoup), donc l'événement InteruptionForm1 non plus (du coup, donner une priorité haute au thread UI ne doit pas changer grand chose). Donc au final ça n'a rien à voir avec des événements "entre threads", vu qu'un événement est traité sur le même thread qui l'a déclenché.

Si c'est trop long, c'est parce que ce que tu fais dans OnEventDeTensionVersInterface prend trop de temps... mais comme je ne sais pas ce que tu y fais, c'est difficile d'identifier le problème pour l'instant.

[Graffito]

Imaginons que l'on veuille avoir un thread de haute priorité pour l'acquisition des mesures et un thread de plus basse priorité pour le traitement des mesures:

• On peut partager entre les 2 threads une liste de mesures,
• Lle thread de haute priorité alimente la liste (en faisant un lock lors de l'ajout),
• le thread de basse priorité extrait la première mesure de la liste et la supprime (en faisant un lock lors de cette extraction/suppression),
• le thread de basse priorité traite la mesure extraite.

[DonQuiche]

j'ai un prog avec plusieurs Thread (avec priorité haute) ; quand on envoie un évenement d'un thread à un autre peut on garantir que celui ci est traité rapidement ?
Y a t'il une methode pour améliorer cette gestion des évenements en plus de la priorité du thread.

a) Les priorités sont le seul moyen pour arbitrer la répartition du temps CPU entre les threads.

b) Des interactions entre threads de priorités différentes peuvent conduire un thread de haute priorité à se comporter comme un thread de basse priorité s'il se trouve à attendre un thread de basse priorité.

c) La granularité du planificateur est de 15ms par défaut (paramètre de l'OS). Autrement dit l'OS ne redistribue le temps CPU que toutes les 15ms (ou avant cela si un thread est arrêté ou mis en attente). Il est possible de réduire cette granularité en initialisant un "timer multimédia" dans le processus. Celle-ci sera alors de 100µs pour tout le système si je ne m'abuse (à vérifier). C'est ce qui explique que certains voient leurs jeux devenir plus réactifs en ouvrant par ailleurs une application de lecture vidéo inactive. Il est aussi possible de modifier les paramètres de démarrage de Windows pour spécifier une granularité plus faible mais cela cause des problèmes de compatibilité.

d) Utilises-tu le ThreadPool ? Si oui, il n'est pas indiqué pour les tâches nécessitant une haute réactivité. Attention à ne pas le saturer.

e) Dans tous les cas il n'est pas possible de consommer plus de temps CPU que ce qui est physiquement possible. Cela paraît évident mais assure-toi que c'est bien un problème de répartition et non un problème de besoins excessifs.

Sur C++ par exemple on a SendMessage et PostMessage qui je crois ne sont pas traités avec la même priorité.
y a t'il quelque chose de comparable ?

Control.Invoke et BeginInvoke appellent respectivement SendMessage et PostMessage (*). Toutefois toutes ces méthodes font passer les messages par la (les) file(s) d'attente win32 et ce mécanisme paraît inutile en-dehors de l'UI, a fortiori dans le monde dotnet, et cela pourrait être une source de problèmes. Si tes threads exploitent ce mécanisme, je te recommande de changer cela et de plutôt utiliser les primitives de synchronisation dotnet (Monitor.XYZ ; EventWaitHandle ; lock) ou les collections concurrentes (BlockingQueue).

Les primitives dotnet sont par ailleurs très optimisées pour la plupart (notamment Monitor.XYZ et lock), ne pars pas du principe que tu auras de meilleures perfs avec les API win32, tu aurais des surprises. Pour ma part j'ai un faible pour de bêtes verrous éventuellement couplés à Monitor.Pulse/Wait.

(*) Je n'ai pas connaissance de priorités différentes associées à ces deux fonctions même si ce ne serait pas illogique. En revanche SendMessage étant synchrone elle crée un couplage entre threads, cf mon point (b).

[lucky]

Bonjour à tous deux,

comme le dit Graffito, j'ai utilisé "Lock", mon système fonctionne bien mais quand j'aurai le temps je l'optimiserai après avoir appris à maitriser les primitives dotnet comme le préconise DonQuiche.
Sinon en ce qui concerne mon Timer j'utilise la classe rapide de précision : http://www.codeproject.com/Articles/...cond-NET-Timer qui fonctionne bien (10ms)

Merci à tout deux