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 | |
---|---|---|
LockManager | Constructeur |
Début
Méthodes
Nom | Description | |
---|---|---|
AssertLockHeld(Object, LockManager.LockType, Int64) | Affirmer que le verrou donné est détenu par le thread actuel (assert debug). | |
AssertLockHeld(ILockName, LockManager.LockType, Int64) | Affirmer que le verrou donné est détenu par le thread actuel (assert debug). | |
AssertLockNotHeld(Object, LockManager.LockType, Int64) | Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug). | |
AssertLockNotHeld(ILockName, LockManager.LockType, Int64) | Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug). | |
AssertNoLocksHeld(Int64) | Affirmer que le thread en cours ne détient aucun verrou LockManager. | |
AssertNoLocksHeld(LockManager.LockType, Int64) | Affirmer que le verrou donné n'est pas détenu par le thread en cours (assert debug). | |
AssertZeroActiveLockObjects | ||
CompareLockTypes | Compare deux verrouiller types (throws si les types de verrous ne sont pas comparables). | |
Equals | Détermine si l'objet spécifié est identique à l'objet actuel. (Hérité de Object.) | |
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.) | |
GetHashCode | Sert de fonction de hachage pour un type particulier. (Hérité de Object.) | |
GetLock(Object, LockManager.LockType, Int64) | Obtenir un verrou. | |
GetLock(ILockName, LockManager.LockType, Int64) | Obtenir un verrou nommé. | |
GetType | Obtient le Type de l'instance actuelle. (Hérité de Object.) | |
Lock(Object, Int64) | Profitez d'une feuille moniteur pour un objet donné. | |
Lock(Object, LockManager.LockType, Int64) | Obtenir un verrou d'objet monitor. | |
Lock(ILockName, LockManager.LockType, Int64) | Obtenir un verrou nommé. | |
MemberwiseClone | Crée une copie superficielle de l'objet Object actuel. (Hérité de Object.) | |
ReleaseAnyLock | Relâchez le verrou plus imbriqué d'un type de verrou donné et n'importe quel nom. | |
ReleaseLock(Object, LockManager.LockType, Int64) | Libérer un verrou. | |
ReleaseLock(ILockName, LockManager.LockType, Int64) | Libérer un verrou nommé. | |
TestLock(Object, LockManager.LockType, Int64) | Tester si ce thread détient déjà un verrou. | |
TestLock(String, LockManager.LockType, Int64) | Tester si ce thread détient déjà un verrou. | |
ToString | Retourne une chaîne qui représente l'objet actif. (Hérité de Object.) | |
TryGetLock(Object, LockManager.LockType, Int64) | Essayez d'obtenir un verrou. | |
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.