2011-04-04 3 views
7

J'ai une classe qui utilise un verrou en lecture-écriture.Test de verrous multi-threads

Je veux voir si j'ai verrouillé et protégé toutes les méthodes correctement.
Existe-t-il un modèle de conception pour un test permettant de vérifier si les verrous sont correctement réglés?

Edit:
Quelques précisions:

Il est un code C# dérivé d'un C++/CLI code qui a des verrous du niveau C++ ... Pas si simple. C'est pourquoi je suis à la recherche d'un design pour un test, pas pour un design pour le verrouiller.

Il y a quelques choses qui doivent être contrôles en multithreading:

Aucun interblocages (plus évident)
Correctness (Si je mets à jour en 1 fil on peut voir dans l'autre)
d'écriture atomique (Si je vous écris dans un thread, je capable de lire que lorsque la valeur totale est écrit)
équité (peut-être plus théorique pour prouver, devrait être vrai si j'utilise Mutex de toute façon)

+8

Est-ce que "soigneusement" compte comme motif de conception? –

+2

Je crains que "soigneusement" ne couvre pas toutes les mauvaises situations –

+0

-1 pour la pire utilisation de 'Design Pattern' de la semaine. – sehe

Répondre

6

Vous pouvez lire sur SyncLock et SyncRoot qui sont utilisés pour créer un modèle commun sur la façon de l arrête tes objets. Puisque vous ne voulez pas verrouiller un objet enitre vous avez souvent un SyncRoot sur lequel vous verrouillez. Un exemple pour ceci est ArrayList ou ICollection qui ont tous deux un SyncRoot que vous devez utiliser pour verrouiller la collection. Vous pouvez en savoir plus sur Thread Synchronization on MSDN.

Mais en général, c'est exactement comme Marc l'a fait remarquer, attention, test, test, test et encore plus de test!

Exemple de SyncLock

public class Person 
{ 
    public decimal Salary { get;set; } 
    public string Name { get; set; } 
    public readonly object SyncRoot = new object(); 
} 

Vous pouvez alors l'approche d'un verrouillage comme celui-ci:

var person = new Person { Name = "Bill", Salary = 1000000 }; 

lock(person.SyncRoot) 
{ 
    IncreasSalary(); 
} 

A bad pattern est de faire lock(this)jamais faire ça!

Il y a aussi quelque chose qui s'appelle Double-checked locking qui n'est pas spécifique à .NET. Vous pouvez aussi lire ce document sur "Strategized Locking, Thread-safe Interface, and Scoped Locking".

Test de la sécurité de fil

Si vous voulez tester la sécurité des threads je vous recommande de vérifier "Unit test for thread safety", les points de réponse acceptée à Microsoft Chess qui peut vous aider à identifier votre application dans les blocages.

+0

C'est un code C# dérivé d'un C++/CLI Code qui a des verrous au niveau C++ ... Pas si simple. C'est pourquoi je suis à la recherche d'un design pour un test, pas pour un design pour le verrouiller. –

+0

@Yochai, donc vous voulez souligner votre demande dans l'impasse? Donc, ce que vous cherchez est une stratégie de test sur la façon de vérifier que votre application ne va pas dans l'impasse? Est-ce exact? –

+0

Tests de multithreading ... Le thread ne se bloque pas. Justice. Les valeurs sont lues correctement, pas au milieu de l'écriture. Il y a plus de multithreading que d'interblocages –

2

Vous connaissez le problème, c'est la première étape. C'est (habituellement) NP-complet ...mais il existe des outils:

  • Helgrind

partie de la boîte à outils valgrind; cela permettra de vérifier l'utilisation des primitives de synchronisation les plus courantes; vous pourriez être en mesure de le dire à propos de vos propres primitives.

  • Intel Parallel Inspector

De même allons-vous décrire vos propres primitives pour la validation en cours d'utilisation. Voir Intel Inspector reports a data race in my spinlock implementation

Mise à jour Je viens de découvrir que GNU libstdc (++) et GNU gcc ont amélioré leur soutien Helgrind substantiellement, reportez-vous aux notes de version 4.6.x et this page

Il relie aussi les autres suivant outils

+0

Sry a raté le tag C#. Il ne devrait pas y avoir de réelle différence, mais il sera plus difficile d'appliquer ces outils – sehe