ReaderWriterLockSlim : ExitWriteLock ne se termine pas [Résolu]

[Arnard]

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 !

[antoine.debyser]

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 :

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?

[Arnard]

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

[antoine.debyser]

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 :

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.

[Arnard]

je l'avais écrit comme cela, mais l'idée y est :

Code :

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 !