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

Framework .NET Discussion :

ReaderWriterLockSlim : ExitWriteLock ne se termine pas


Sujet :

Framework .NET

  1. #1
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Avril 2006
    Messages
    1 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2006
    Messages : 1 627
    Points : 2 331
    Points
    2 331
    Par défaut ReaderWriterLockSlim : ExitWriteLock ne se termine pas
    Hello,

    je rencontre un souci avec le ReaderWriterLockSlim.

    Je l'utilise dans une classe qui a pour charge de gérer des accès à des IO (ports séries et tcp) en fonction de liste d'attente.

    Application en cours d'exécution, je vois mes threads monter, je fais pause, j'affiche la liste des threads, et j'en repère un qui est dans le write, appel à ExitWriteLock en cours, les autres threads étant sur un TryEnterWriteLock dans une autre fonction.

    Je fais un resume du programme, pause quelques secondes plus tard, le thread est toujours en cours d'attente de la fin du ExitWriteLock, et mes autres threads s'accumulent à la porte d'entrée.

    Pour ExitWriteLock ne rend pas la main dans ce cas de figure ?

    Merci pour votre aide !

  2. #2
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 269
    Points : 460
    Points
    460
    Par défaut
    Bonjour,

    Ton cas est un peu bizarre, ceci n'est pas censé arrivé.
    Et tu sur de bien avoir acquis le verrou, avant de vouloir le relâcher, en vérifiant bien le retour de TryEnterWriteLock comme ceci

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    if (cacheLock.TryEnterWriteLock(timeout))
        {
            try
            {
                innerCache.Add(key, value);
            }
            finally
            {
                cacheLock.ExitWriteLock();
            }
            return true;
        }
    Ton verrouillage d’écriture ce fait-il dans un verrou de lecture?
    As tu autorisé le verrouillage récursif?

  3. #3
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Avril 2006
    Messages
    1 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2006
    Messages : 1 627
    Points : 2 331
    Points
    2 331
    Par défaut
    Hello.

    pas de récursion. je try/finally pour quitter le lock (après un TryEnter et test du booléen en entrée/sortie).

    Mais j'ai trouvé un élément qui explique ce fait, readWriteLockSlim n'est pas safe sur un Thread.abort contrairement à Monitor.Enter.

    Actuelleemnt j'ai revu mon code pour exclure les ReadWriteLockSlim et utiliser les ConcurrencyDictionnary

    Edit : les Liens
    http://stackoverflow.com/questions/1...any-properties
    http://www.bluebytesoftware.com/blog...c-7847d98f1641
    http://www.bluebytesoftware.com/blog...b90a7d11a.aspx

  4. #4
    Membre confirmé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mars 2011
    Messages
    269
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2011
    Messages : 269
    Points : 460
    Points
    460
    Par défaut
    C'est vrai que Thread.Abort c'est assez brutal.
    Mais dans le cas présent j'ai raté un truc. La façon dont le "TryEnter" est écrit n'est pas du tous tolérante au exception
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
     
    bool isEnter = false;
    try
    {
      isEnter = cacheLock.TryEnterWriteLock(timeout);
      //Faire le travail
    }
    finaly
    {
      if (isEnter)
        cacheLock.ExitWriteLock();
    }
    Bon c'est pas encore le meilleurs code, à cause du Abort, qui peut empêcher l'affectation correct de la variable isEnter.
    Ce problème peut facilement être contournable, en n'utilisant pas Abort, mais une condition d’arrêt sur le thread.

  5. #5
    Membre émérite
    Homme Profil pro
    Développeur .NET
    Inscrit en
    Avril 2006
    Messages
    1 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2006
    Messages : 1 627
    Points : 2 331
    Points
    2 331
    Par défaut
    je l'avais écrit comme cela, mais l'idée y est :

    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
     
    bool res = false;
    try
    { 
       res = verrou.TryEnterWriteLock(timeout, ref res);
     
       if(res)
       {
          //J'ai le pouvoir, AHAHAHAH
       }
    }
    finally
    {
       if(res)
          verrou.ExitWriteLock();
    }
    Pour Thread.Abort, oui, j'ai d'ailleurs rajouté un flag d'arrêt, mais je ne veux pas qu'un thread puisse demeurer trop longtemps (communication IO a reporter ailleurs), donc tôt ou tard soumis à potentiellement à un thread.abort. Le cas de figure que ça puisse arriver lors du try Enter est de l'ordre de 0.0..1% mais pour un code qui tourne H24, ça le fait pas !

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

Discussions similaires

  1. WM_QUIT ne termine pas mon application !
    Par syj dans le forum Visual C++
    Réponses: 7
    Dernier message: 10/11/2006, 12h21
  2. Terminate() qui ne terminate pas
    Par kurkaine dans le forum C++Builder
    Réponses: 5
    Dernier message: 19/06/2006, 22h05
  3. Frame et terminal pas d'accord....
    Par superjoe dans le forum 2D
    Réponses: 3
    Dernier message: 23/03/2006, 16h30
  4. [AJAX] Ma fonction ne se termine pas...
    Par Davboc dans le forum Général JavaScript
    Réponses: 17
    Dernier message: 08/03/2006, 13h05
  5. [TTHREAD] ne termine pas sont exécution
    Par Bbenj dans le forum Langage
    Réponses: 4
    Dernier message: 02/08/2002, 17h42

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