Pourquoi le deuxième thread est-il publié avant le premier, quand ils ont tous deux appelé WaitOne() et ont été libérés par un AutoResetEvent?

Question

Supposons que ThreadA et ThreadB appellent tous deux WaitOne() dans cet ordre sur le même AutoResetEvent. Lorsque l'événement est défini, pourquoi ThreadB est-il libéré au lieu de ThreadA?

J'ai couru un test pour savoir ce qui se passe lorsque vous définissez un AutoResetEvent sur lequel mutiple threads attendent:

private static void Test() 
    { 
     // two threads - waiting for the same autoreset event 
     // start it unset i.e. closed i.e. anything calling WaitOne() will block 
     AutoResetEvent autoEvent = new AutoResetEvent(false); 

     Thread thread1 = new Thread(new ThreadStart(WriteSomeMessageToTheConsole)); 
     thread1.Start(); // this will now block until we set the event 

     Thread thread2 = new Thread(new ThreadStart(WriteSomeOtherMessageToTheConsole)); 
     thread2.Start(); // this will now also block until we set the event 

     // simulate some other stuff 
     Console.WriteLine("Doing stuff..."); 
     Thread.Sleep(5000); 
     Console.WriteLine("Stuff done."); 

     // set the event - I thought this would mean both waiting threads are allowed to continue 
     // BUT thread2 runs and thread1 stays blocked indefinitely 
     // So I guess I was wrong and that Set only releases one thread in WaitOne()? 
     // And why thread2 first? 
     autoEvent1.Set(); 
    } 

Le code est bien sûr pas utile; c'est juste un exemple de souris mickey. Et ce n'est pas important/urgent. Mais je serais intéressé à en savoir plus quand même ...

Answer 1

IIRC, thread qui est libéré par un événement de réinitialisation automatique est non spécifiée. Comme tout le monde dit d'autre, vous voulez un événement de réinitialisation manuelle si vous souhaitez diffuser une condition. Si vous voulez libérer un nombre exact (disons exactement 3 de n), alors vous voudrez probablement utiliser un sémaphore

Si vous voulez vraiment comprendre pourquoi la commande pourrait être différente de ce que vous attendez, jetez un oeil à "Windows Internals" ou quoi que ce soit que Mark Russinovich a écrit. il y a des chances qu'il explique l'ordre d'attente sur les ressources exécutives quelque part.

Answer 2

Sur un AutoResetEvent, Set ne libère un fil. Vous devez utiliser un ManualResetEvent pour libérer plusieurs threads en attente.

Answer 3

De MSDN

MSDN sur ManualResetEvent:. « Threads qui appellent WaitOne sur le ManualResetEvent bloque, en attente d' le signal Lorsque le fil contrôle complète l'activité, il appels réglés pour vous signaler les threads en attente peuvent continuer. Tous les threads en attente sont libérés.

Mais pour AutoResetEvent, MSD N dit: « Appel Set signaux AutoResetEvent à sortie un fil d'attente. AutoResetEvent reste signalé jusqu'à ce que un thread d'attente unique soit libéré, puis automatiquement revient à l'état non signé. Si pas de fils en attente, l'état reste indéfiniment signalé.

"