Discussion :

[mackhdo]

Bonjour,

Ayant cherché pas mal et n'ayant pas trouvé de réponses satisfaisantes, je me permet de poser mon problème ici, en espérant qu'un âme charitable trouve une solution.

Donc j'ai un control avec une event KeyDown, et je veux déclencher une action quand deux touches précises sont enfoncées simultanément.

voici le code:

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
       private void globalEventProvider1_KeyDown(object sender, KeyEventArgs e)
       {
           if (e.KeyCode == keyOne)
           {
               KeyOnePressed = true;
           }
           if (e.KeyCode == keyTwo)
           {
               KeyTwoPressed = true;
           }
           if (e.KeyCode == keyOne ||e.KeyCode == keyTwo)
           {
                     var t = new Thread(criticalSection);
                     t.Start();
                     t.Join();
           }
 
       }
 
       private static Semaphore sem = new Semaphore(1, 1);
 
       private void criticalSection()
       {
           sem.WaitOne();
           if (KeyOnePressed && KeyTwoPressed)
           {
               KeyOnePressed = false;
               KeyTwoPressed = false;
               MessageBox.Show("OK");
           }
           sem.Release();
       }

Le problème ici est que comme vous pouvez le constater j'utilise un thread séparé pour l'action finale.

J'en suis arrivé la car si je met le code de ce thread directement dans la première fonction, la message box se lance toujours deux fois.

J'ai essayer de protéger se morceau de code avec un lock, un mutex, rien n'y fait.

Si on appui sur deux touches en simultané, deux threads se lancent pour gérer les évènements des touches, ils sont différents mais pourtant les restrictions tels que le lock ou le mutex ne s'applique pas a eux.

Comme si c'était un seul et unique thread.

J'aimerais qu'on m'explique simplement pourquoi le lock ou le mutex ne marche pas dans ce cas précis et s'il existe une façon plus propre que mon code pour le faire.

En passant, cela pourrait il avoir un rapport avec le nombre de coeurs du processeur ?

Merci et bonne journée.

[Arnard]

Hello,

même si tu appuies sur tes 2 touches en simultanées, tu auras toujours un léger décalage temporel (de l'ordre de la dizaine de ms), donc tu appelleras toujours ta méthode criticalSection 2 fois.

* T1 instancié
* T2 instancié
* T1 obtient le mutex, il rentre dans la section critique
* T2 juste après bloqué sur le WaitOne
* T1 Release
* T2 obtient mutex et re-traite

Un seul thread d'appel doit être créé. Si tu veux en créer plusieurs, utilise return dans la section critique près avoir checké tes arguments plutôt que de faire des wait

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
private void globalEventProvider1_KeyDown(object sender, KeyEventArgs e)
{
if (e.KeyCode == keyOne)
{
KeyOnePressed = true;
}
if (e.KeyCode == keyTwo)
{
KeyTwoPressed = true;
}
if (KeyOnePressed  && KeyTwoPressed ) //on déplace le test, si on a les deux touches actives on est bons !
{
var t = new Thread(criticalSection);
t.Start();
t.Join(); //utile  ???
}

et tu peux virer les sémaphores de ta section critical

[mackhdo]

il manque un bout de code en fait.

En réalité il y a un aussi un event keyup ou je met les boolean keyonepressed et keytwopressed a false.

C'est pas exactement ce que tu crois, l'intérêt du sémaphore ici est que justement il n'autorise qu'un seul thread a faire l'action et vu que ce thread remet les deux boolean a false, quand le deuxième thread récupère le sémaphore la condition n'est plus respecté (les deux boolean sont a false) donc il n'exécute pas le code.

C'est la seule façon que j'ai trouvé actuellement pour que le code s'exécute une seule fois.

Si je fais comme tu me dis (car je l'ai déjà tenté), le code de la section critique sera exécuté deux fois, et c'est exactement ce que je ne veux pas.

Si on appuie vraiment simultanément sur les deux touches, la différence entre les deux thread est d'une seule instruction, donc avant même que les variables soient remises a false les deux thread sont dans le codes critique.

J'utilise un thread car celui ci, une fois lancé par chaque thread entrant, est bien reconnu comme différent par l'application, donc le sémaphore fonctionne.

Si j'enlève l'appel du thread, le sémaphore ne fonctionne plus, car l'application considère les deux thread entrant dans le keypress comme un seul thread !!

C'est la tout mon problème, j'aimerais déjà dans un premier temps comprendre comment deux thread peuvent être considérés comme un seul.

Merci de ta réponse en tout cas.

EDIT: je vois que tu viens d'éditer du coup tout ma réponse ne correspont plus à la tienne, je la laisse néanmoins pour le complément d'infos.
Mais dans ta dernière édition je vois un truc auquel je n'avais pas pensé qui est surement une solution, c'est le return. Mais cela ne me donne toujours pas la réponse que je cherche.

[Arnard]

Le fait d'utiliser des sémaphores introduit peut-être une notion de contexte distinct, je ne sais pas là :/

Ce qui est intéressant, c'est que tu mets tes variables à false, et derrières elles valent true. Si c'est des propriétés, tu peux tracer le get et le set, avec identifiant du thread sur chaque appel ? A mon sens c'est piger le pourquoi de ce changement des valeurs sur tes booléens

[mackhdo]

Je vais tenter de détailler encore plus le contexte.

j'ai deux machines différentes:
- une avec XP 32 bit et un core 2 duo, on l'appellera XP.
- une avec Seven 64 bit et un phenom X3, on l'appellera Seven.
-DotNet 3.5 sur les deux machines.
Si l'on considère le morceau de code suivant:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
private void textBox1_KeyDown(object sender, KeyEventArgs e)
        {
            if (e.KeyValue == 111)
            {
                KeyOnePressed = true;
            }
            if (e.KeyValue == 106)
            {
                KeyTwoPressed = true;
            }
                         if (KeyOnePressed && KeyTwoPressed)
                {

Le contexte est le suivant:
-KeyOnePressed et KeyTwoPressed sont à false par défaut.
-KeyValue 111 correspond a la touche [/]
-KeyValue 106 correspond a la touche[*]

On appuie simultanément sur[*] + [/].
-Sur seven, deux thread s'executent en parallèle, chacun gérant un keypress.
De ce fait le thread gerant [/] va passer KeyOnePressed a true et le thread gerant[*] va passer KeyTwoPressed a true, si bien que les deux thread vont arriver en même temps a la partie

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
                          if (KeyOnePressed && KeyTwoPressed)
                {

et vu que les deux boolean sont a true a cet instant, les deux thread vont entrer dans la section.

-Sur XP, les thread s'exécutent l'un après l'autre, le premier thread gerant [/] va passer KeyOnePressed a true et en arrivant au test, la condition n'étant pas remplie ( KeyTwoPressed est false), va s'arrêter.
Le deuxième thread gerant[*] s'execute a son tour et va passer KeyTwoPressed a true, arrivé au test, la condition est remplie, les deux boolean sont a true, il exécute le code.


Voila tout ceci pour expliquer clairement que sur la machine XP je n'ai pas de problème, le code après la condition s'exécute une seule fois comme souhaité, mais sur la machine seven deux fois.

Comment puis je faire pour qu'il ne s'exécute qu'une fois, de façon optimale j'entends, et surtout pourquoi je ne puis le faire sans passer par un thread intermédiaire, ce que je trouve particulièrement crade en passant.

Je cherche plus a comprendre ce qu'il se passe dans un premier temps qu'une réelle solution, je préférait grandement savoir, puis essayer de trouver la solution par moi même.

J'ai lu beaucoup de choses sur le net sur les thread et les processeurs multicoeur, mais je n'ai vu nulle part le lien avec les lock() ou les sémaphores.

Si un expert dans le domaine pouvait ne serait ce que me donner des pistes de lecture, je lui en serais gré.

Désolé pour le pavé, mais ce problème me tient a cœur.

[Guulh]

Je vois pas bien pourquoi tu t'embêtes avec des threads...

Ce que tu veux, c'est juste déclencher une action quand deux touches déterminées sont appuyées simultanément ?
Il me semble qu'il te suffit de garder un booléen pour chaque touche, mis à true dans le keydown et à false dans le keyup, et déclencher ta méthode (l'appel de messagebox ici) uniquement si tes deux booléens sont true.

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
private void bidule_KeyDown(object sender, KeyEventArgs e)
{
  if (e.KeyCode == keyOne)
    KeyOnePressed = true;
  else if (e.KeyCode == keyTwo)
    KeyTwoPressed = true;
  if (KeyOnePressed && KeyTwoPressed)
    MessageBox.Show("Victoire !");
}
 
private void bidule_KeyUp(object sender, KeyEventArgs e)
{
  if (e.KeyCode == keyOne)
    KeyOnePressed = false;
  else if (e.KeyCode == keyTwo)
    KeyTwoPressed = false;
}

Quel rapport avec les threads ?

[Arnard]

Première solution que je lui ai proposé, le test direct sur les deux booléens, mais il maintient que 2 appels à son handler sont faits en parallèle, ce que je pige pas vu qu'il n'y a qu'un seul thread UI.

[mackhdo]

J'ai remis un gros pavé détaillé en clair exprès pour bien expliquer le problème, mais a priori cela ne doit encore pas être assez clair, sauf que la je vois plus trop ce que je peux faire pour expliquer...

Donc pour être le plus explicite possible:
@Guulh: ce que tu mets c'est exactement ce que j'ai mis dans l'exemple au dessus, et si tu lis bien je dis que le code se déclenche deux fois, la messagebox apparait deux fois.

@Arnard: il y a deux thread, un pour chaque event, tu le verras si tu essaye le code.

maintenant je suis quasiment certain que cela a un rapport avec le type de processeur et/ou le système d'exploitation en x86 ou x64, mais il me faut un expert dans ce domaine pour m'éclairer.

J'apprécie vraiment que vous essayez de m'aider, sincèrement, mais je pense que vous ne comprenez pas ce qu'il se passe exactement.

EDIT: Une précision qui peut être utile, le handler de l'event n'est pas un simple handler de textbox ou autre, il provient d'une classe qui fournit un hook du clavier, c'est a dire que ce code est exécuté même si l'appli n'est pas la form active.

[Arnard]

Donc ce n'est pas le thread de l'UI, je comprends mieux... Si tes notifications se font en asynchrones, ca explique les deux threads comme source...

Je vois le souci. Un simple lock ne suffit pas en effet, vu que tu vas tester tes conditions deux fois, et quelles seront vrais les deux fois, même en mettant à false tes booléens. Une solution pourrait être la gestion d'un flag avec Interlocked. A quelle fréquence souhaites-tu appuyer sur ces touches ?

Une option B plus simple serait de mémoriser le DateTime d'entrée dans le lock au premier coup et de faire un calcul d'écart au deuxième coup, et si l'écart est en dessous de la seconde, annuler le deuxième appel

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
 
private datetime dateLastWork = DateTime.Today; //Initialisation
 
void KeyPressed()
{
  //TEST
 
  if(one && two)
    work();
}
 
void work()
{
  lock(tonVerrou)
  {
     if((DateTime.now - dateLastWork).TotalMilliSeconds < 1000) //si inférieur à la seconde, on quitte
          return;
 
    dateLastWork = DateTime.Now; //Avant messagebox pour éviter un faux temps
    MessageBox();  
  }
}

EDIT : version équivalente plus light, remplacer lock et datetime par Monitor.TryEnter(Object verrou, int tempsAvantTimeout, bool verrouObtenu). Si timeout, tu ne traites pas à la suite. Un timeout de 100ms devrait le faire

[mackhdo]

Je suis content que tu ai compris mon problème, on va pouvoir avancer.

Dans ton code, je ne vois pas l'intérêt de faire une fonction work() séparé, il y a une raison précise ?

Je comprends ce que fait ton code mais je ne suis pas sur que ce soit mieux que ma solution actuelle, si tel est le cas, peut tu m'expliquer en quoi c'est plus optimisé ?

Dernière question, tu dis que le lock ne marche pas la ou le monitor lui fonctionnera, pourquoi cela ?

Sinon je ne peux malheureusement pas tester de suite ton code car je n'ai que la machine xp sous la main, j'aurais la seven ce soir seulement.

[Arnard]

Dans ton code, je ne vois pas l'intérêt de faire une fonction work() séparé, il y a une raison précise ?

Non aucune, j'ai simplement gardé ton découpage au premier post

Je comprends ce que fait ton code mais je ne suis pas sur que ce soit mieux que ma solution actuelle, si tel est le cas, peut tu m'expliquer en quoi c'est plus optimisé ?

Que ça fonctionne si je ne suis pas trop nunuche xD. Et qu'un sémaphore est beaucoup plus couteux qu'un lock qui est déjà très couteux... Comme tu as deux threads différents il faut pouvoir regrouper le fonctionnel en un passage unique

Dernière question, tu dis que le lock ne marche pas la ou le monitor lui fonctionnera, pourquoi cela ?

Lock est simplement du sucre synthaxique pour un monitor. L'intérêt est le time out, qui va empêcher de traiter une opération 2 fois si bien paramétré (j'ai indiqué 100ms, mais ça peut être moins).

Sinon je ne peux malheureusement pas tester de suite ton code car je n'ai que la machine xp sous la main, j'aurais la seven ce soir seulement.

Pas de souci.

[Guulh]

Puisque tu bosses avec les winforms, tu peux en profiter pour utiliser la méthode Invoke, qui va exécuter le code que tu lui files en paramètre dans le thread de l'UI. De cette façon, même si deux threads différents en viennent à appeler tes bidule_KeyDown/KeyUp, au final le traitement de tes booléens se fera toujours dans le même thread, et plus besoin de locks ou de sémaphores.

Au passage, il me parait bien louche que ton composant (celui ci, de CodeProject, si je me fie à son nom ?) balance des events dans différents threads. Essaie de logger tout ce qui se passe, en incluant dans le log le numéro du thread (Thread.CurrentThread.ManagedThreadId)

[Arnard]

Le coup de rediriger vers le thread UI comme accès unique est une idée aussi, le coût sera plus faible sans doute que le lock.

Pour les events, s'ils sont générés en asynchrone, quoi de plus logique ?

[Guulh]

Pour les events, s'ils sont générés en asynchrone, quoi de plus logique ?

Que veux tu dire par là ? Les events ne sont qu'une implémentation du pattern observer, ils n'ont rien à voir avec la programmation concurrente. Si vraiment la classe émettrice est amenée à lever des events depuis d'autres threads, on peut la concevoir pour qu'elle prenne dans son constructeur un ISynchronizeInvoke en paramètre, de façon à lever les events dans le thread qui arrange son abonné.

[Arnard]

Il y a deux manières de lever un événement en .Net : synchrone et asynchrone. Je suis d'accord pour le pattern observer... Mais :

Synchrone : l'appel est fait dans le même thread, de manière séquencé (obj1 puis obj2 puis...)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
if(myEvent != null))
   myEvent();

Asynchrone : chaque appel se fait dans un thread distinct

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
if(myEvent != null))
{
   Delegate[] abonnes = EtatTcpIpConnexionChanged.GetInvocationList();
   foreach(Delegate deleg in abonnes)
   {
        ((CustomDelegateType)deleg).BeginInvoke(/*Params selon délégués*/);
   }
}

En l'occurence mackhdo ne maitrise pas la manière dont les events sont levés...

Edit : je vais jeter un œil à ISynchronizeInvoke

[Guulh]

Il y a deux manières de lever un événement en .Net : synchrone et asynchrone.

Comme tu le montres, un event n'est qu'une collection de méthodes, que le propriétaire (i.e. la classe émettrice) peut lancer de la façon qu'il veut ; mais il n'y a aucun lien particulier entre les deux concepts.
C'est comme si tu disais "une string est soit public, soit private, soit internal, soit protected". Certes oui, mais ce n'est pas propre aux strings.

Du reste, je ne vois pas trop le genre de scénario où l'on voudrait que ce soit l'émetteur qui impose inutilement de coder concurrentiellement. Si par exemple l'émetteur a un traitement dans un worker thread (une notification réseau, par exemple), ça peut se justifier. Mais dans ce cas là, comme je disais tout à l'heure, il vaut mieux avoir une propriété du type ISynchronizeInvoke, pour faciliter la vie des abonnés.
C'est plutôt à l'abonné, derrière, de mettre en place du threading si besoin.