Partager via


LockManager, classe

Classe LockManager.

Hiérarchie d'héritage

System.Object
  Microsoft.TeamFoundation.Framework.Server.LockManager

Espace de noms :  Microsoft.TeamFoundation.Framework.Server
Assembly :  Microsoft.TeamFoundation.Framework.Server (dans Microsoft.TeamFoundation.Framework.Server.dll)

Syntaxe

'Déclaration
Public Class LockManager
public class LockManager

Le type LockManager expose les membres suivants.

Constructeurs

  Nom Description
Méthode publique LockManager Constructeur

Début

Méthodes

  Nom Description
Méthode publique AssertLockHeld(Object, LockManager.LockType, Int64) Affirmer que le verrou donné est détenu par le thread actuel (assert debug).
Méthode publique AssertLockHeld(ILockName, LockManager.LockType, Int64) Affirmer que le verrou donné est détenu par le thread actuel (assert debug).
Méthode publique AssertLockNotHeld(Object, LockManager.LockType, Int64) Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug).
Méthode publique AssertLockNotHeld(ILockName, LockManager.LockType, Int64) Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug).
Méthode publique AssertNoLocksHeld(Int64) Affirmer que le thread en cours ne détient aucun verrou LockManager.
Méthode publique AssertNoLocksHeld(LockManager.LockType, Int64) Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug).
Méthode publique AssertZeroActiveLockObjects
Méthode publiqueMembre statique CompareLockTypes Compare deux verrouiller types (throws si les types de verrous ne sont pas comparables).
Méthode publique Equals Détermine si l'objet spécifié est identique à l'objet actuel. (Hérité de Object.)
Méthode protégée Finalize Autorise un objet à tenter de libérer des ressources et d'exécuter d'autres opérations de nettoyage avant qu'il ne soit récupéré par l'opération garbage collection. (Hérité de Object.)
Méthode publique GetHashCode Sert de fonction de hachage pour un type particulier. (Hérité de Object.)
Méthode publique GetLock(Object, LockManager.LockType, Int64) Obtenir un verrou.
Méthode publique GetLock(ILockName, LockManager.LockType, Int64) Obtenir un verrou nommé.
Méthode publique GetType Obtient le Type de l'instance actuelle. (Hérité de Object.)
Méthode publique Lock(Object, Int64) Profitez d'une feuille moniteur pour un objet donné.
Méthode publique Lock(Object, LockManager.LockType, Int64) Obtenir un verrou d'objet monitor.
Méthode publique Lock(ILockName, LockManager.LockType, Int64) Obtenir un verrou nommé.
Méthode protégée MemberwiseClone Crée une copie superficielle de l'objet Object actuel. (Hérité de Object.)
Méthode publique ReleaseAnyLock Relâchez le verrou plus imbriqué d'un type de verrou donné et n'importe quel nom.
Méthode publique ReleaseLock(Object, LockManager.LockType, Int64) Libérer un verrou.
Méthode publique ReleaseLock(ILockName, LockManager.LockType, Int64) Libérer un verrou nommé.
Méthode publique TestLock(Object, LockManager.LockType, Int64) Tester si ce thread détient déjà un verrou.
Méthode publique TestLock(String, LockManager.LockType, Int64) Tester si ce thread détient déjà un verrou.
Méthode publique ToString Retourne une chaîne qui représente l'objet actif. (Hérité de Object.)
Méthode publique TryGetLock(Object, LockManager.LockType, Int64) Essayez d'obtenir un verrou.
Méthode publique TryGetLock(ILockName, LockManager.LockType, Int64, Int32)

Début

Notes

Banque géré pratiques à éviter les verrous mortels.Verrouillage tous doit utiliser les verrous LockManager.Chaque verrou est affecté à un niveau (une position dans la hiérarchie de verrouillage), et toute opération peut uniquement les verrous de demande sont supérieurs dans la hiérarchie à n'importe quel verrou actuellement détenu.

LockManager prend en charge le concept de « nommé verrous », e.g. lorsque nous devons verrouiller certaines entité pour lequel nous pouvons pas un objet stable en mémoire, mais ont simplement un nom de cette entité.Boîte aux lettres et la base de données sont des exemples.Tout objet associé à la boîte aux lettres ou de la base de données peut et viennent, tout nous avons stable pour cette entité est son nom, comme un GUID de la base de données pour un nombre de base de données ou boîte aux lettres pour une boîte aux lettres.Nous prend en charge les verrous de moniteur et lecteur-writer pour verrous nommées.

LockManager prend également en charge ordinaire "objet" verrous, lorsque nous devons verrouiller une instance d'objet particulier dans la mémoire.Seuls les moniteur verrous sont actuellement pris en charge pour les verrous d'objet, qui sont le même verrouillage mécanisme tel qu'utilisé dans l'instruction c# lock « ».Contrairement à l'instruction « verrou », LockManager verrou d'objet participe pleinement à une hiérarchie de verrouillage, donc nous pouvons vérifier qu'ils sont utilisés dans un ordre correct.

Un cas spécial de « verrou d'objet » est un « verrou d'objet feuille ».Nous n'avons pas spécifier le niveau de verrouillage pour ce type de verrou - il devrait être toujours un verrou imbriqués de la plupart et aucun autres verrous ne peuvent être prises lorsque le verrou de ces feuilles.

« Nommé verrous » est implémenté par dynamiquement l'allocation d'un objet lock pour chaque nom unique et en les stockant dans un dictionnaire global.Donc accéder à un verrou nommé par nom nécessite recherche dans le dictionnaire pour trouver un objet lock correspondante.Le dictionnaire d'objets de verrou doit être lui-même verrouillé pendant que vous effectuez une telle recherche.Tout ceci rend verrous nommés potentiellement plus chers que les verrous ordinaires, en raison du coût supplémentaire de verrouillage du dictionnaire et une recherche dans le dictionnaire.Nous utilisons deux techniques pour réduire ces coûts : dictionnaire d'objets lock, afin de réduire la contention de verrouillage global dictionnaire, le partitionnement (1) et (2) l'appelant ce qui permet de mettre en cache la référence d'objet nommé lock et ignorer la recherche dans le dictionnaire la plupart du temps.Notez que seul le partitionnement est insuffisant, car il ne vous aide pas beaucoup avec des verrous de portée relativement, comme un verrou de base de données ; par exemple, lorsque tout le monde veut attrapez la même partagée lock.

Il existe un nombre potentiellement illimité des noms uniques de verrou.Par conséquent, le nombre d'objets lock nommé que nous pouvons créer potentiellement est également illimité.Références aux objets de verrou nommés sont stockés dans un dictionnaire global, ces objets pourraient jamais être nettoyée automatiquement.Nous souhaitons donc pouvoir nettoyer nommé verrouiller les objets qui ne sont pas utilisés régulièrement.Pour prendre en charge de nettoyage de thread-safe des objets nommés lock, ces objets sont refcounted.Chaque verrou pris sur un objet nommé lock nécessite vu tel objet « addrefed », la référence doit être libérée après que le verrou est libéré.Logique de nettoyage vérifie que l'objet n'est pas référencé avant de le supprimer à partir du dictionnaire.Après la suppression d'un objet lock nommée à partir d'un dictionnaire, il est marqué comme supprimé et ne peut pas être plus addrefed.Une tentative de verrouiller le même nom lors de la prochaine provoquera allouer un nouvel objet nommé verrou qui porte le même nom et en l'ajoutant à un dictionnaire.Donc c'est OK d'avoir obsolètes appelé verrou objet références mises en cache par un appelant - telle référence périmé est détecté et mis à jour la prochaine fois que nous essayons de le verrouiller et allouer un nouvel objet lock.

Nous utilisons une heuristique temps simple basé pour nettoyer des objets inutilisés de verrou.Sur toutes les n nommé appels de libération du verrou que nous vérifier s'il existe un temps d'exécuter le nettoyage et puis examinez le dictionnaire et collecter tous les objets non référencés qui ne sont pas utilisés récemment.Puis nous tenter dispose de tous ces objets et supprimer sa référence d'un dictionnaire.Le nettoyage est par partition de dictionnaire, afin que nous n'avons pas à verrouiller les autres partitions lorsque nous exécutons le nettoyage pour une partition donnée.

Sécurité des threads

Tous les membres static (Shared en Visual Basic) publics de ce type sont thread-safe. Il n'est pas garanti que les membres d'instance soient thread-safe.

Voir aussi

Référence

Microsoft.TeamFoundation.Framework.Server, espace de noms