IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

C# Discussion :

Synchronisation de thread avec ManualResetEvent [Débutant]


Sujet :

C#

  1. #1
    Membre éprouvé Avatar de noOneIsInnocent
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    1 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 037
    Points : 1 161
    Points
    1 161
    Par défaut Synchronisation de thread avec ManualResetEvent
    Bonjour

    J'ai récupéré une application qui fait appel à une autre application pour communiquer en TCP.
    Mon application bloque les demandes entrantes en utilisant la classe avec un Timeout
    Ma question est la suivante: supposons que je n'ai pas de réponse de l'application tierce, dans ce cas là la méthode WaitOne(Timeout) doit retourner false. Dans ce cas est-ce que je dois appeler la méthode Set ?
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    ManualResetEvent mre = new  ManualResetEvent(false);
    boolean isResponseReceived = mre.WaitOne(30000);
     
    if (isResponseReceived) {
     ///ICI est-ce que j'ai besoin de faire mre.Set();
    }
    Et même dans le cas où j'ai une réponse du coup est-ce que je dois bien faire
    Et enfin dernière question j'ai du mal à saisir la différence entre Set et Reset

    Merci

  2. #2
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 154
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 154
    Points : 25 072
    Points
    25 072
    Par défaut
    waitone attend
    appeler set sur l'objet débloque le wait (je crois qu'il y a possibilité de ne pas donner de timeout d'ailleurs)
    reset doit permettre de s'en resservir

    après si tu attends une réponse tcp je ne vois pourquoi tu aurais besoin de manualresetevent qui sert plutot pour du multithreading que du timeout
    que tu utilises beginread ou un thread tu peux te faire ton timeout avec un simple timer ou un sleep
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  3. #3
    Membre éprouvé Avatar de noOneIsInnocent
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    1 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 037
    Points : 1 161
    Points
    1 161
    Par défaut
    Merci pour ta réponse
    Sinon on est en multithreading d'où l'utilisation de manuelresetevent
    Du coup j'ai une autre question: Est-ce que il faut utiliser reset après le set ?
    Et autre question j'ai vu dans la doc que il y a bien un timeout. Que se passe il une fois le timeout passé?
    Est ce que le lock est toujours positionné et il faut faire un set ?
    Si quelqu'un a un tuto clair je suis preneur?

  4. #4
    Expert éminent sénior Avatar de Pol63
    Homme Profil pro
    .NET / SQL SERVER
    Inscrit en
    Avril 2007
    Messages
    14 154
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : .NET / SQL SERVER

    Informations forums :
    Inscription : Avril 2007
    Messages : 14 154
    Points : 25 072
    Points
    25 072
    Par défaut
    je persiste à dire que je ne comprends pourquoi un manualresetevent pour gérer un timeout de tcp

    après c'est une classe très simple avec peu de membres donc tu peux te faire un projet de test pour comprendre le fonctionnement réel de la classe avec quelques lignes de code
    Cours complets, tutos et autres FAQ ici : C# - VB.NET

  5. #5
    Membre éprouvé Avatar de noOneIsInnocent
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    1 037
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2002
    Messages : 1 037
    Points : 1 161
    Points
    1 161
    Par défaut
    Désolé si je me suis mal exprimé mais le manuelresetevent n'est pas utilisé pour gérer un timeout de TCP. En revanche il est utilisé pour bloqué toutes nouvelles requêtes
    Sinon j'ai trouvé un lien qui explique en termes clairs le fonctionnement:
    http://dotnetpattern.com/threading-manualresetevent

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 13
    Dernier message: 11/06/2015, 15h51
  2. [WD17] Synchronisation de threads avec signaux, comportement bizarre
    Par droliprane dans le forum WinDev
    Réponses: 7
    Dernier message: 08/10/2014, 18h57
  3. Synchronisation des threads avec deux sémpahores
    Par pupucette dans le forum C++
    Réponses: 0
    Dernier message: 27/01/2013, 22h17
  4. Synchronisation de Threads avec un systeme de signal/event
    Par Niklaos dans le forum Threads & Processus
    Réponses: 23
    Dernier message: 03/01/2010, 19h01
  5. Synchronisation thread avec boolean
    Par the_ionic dans le forum Débuter avec Java
    Réponses: 4
    Dernier message: 01/09/2008, 15h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo