LockManager, classe

Classe de 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)	Affirmez que le verrou donné est géré par le thread actuel (assertion de débogage).
	AssertLockHeld(ILockName, LockManager.LockType, Int64)	Affirmez que le verrou donné est géré par le thread actuel (assertion de débogage).
	AssertLockNotHeld(Object, LockManager.LockType, Int64)	Affirmez que le verrou donné n'est pas géré par le thread actuel (assertion de débogage).
	AssertLockNotHeld(ILockName, LockManager.LockType, Int64)	Affirmez que le verrou donné n'est pas géré par le thread actuel (assertion de débogage).
	AssertNoLocksHeld(Int64)	Affirmez que le thread en cours ne contient aucun verrouillage du LockManager.
	AssertNoLocksHeld(LockManager.LockType, Int64)	Affirmez que le verrou donné n'est pas géré par le thread actuel (assertion de débogage).
	AssertZeroActiveLockObjects	Les assertions IFF impliquent les verrous actifs dans le gestionnaire de verrous (où &amp de refcount ; le GT ; 0)
	CompareLockTypes	Compare deux types de verrous (lève une exception 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 par défaut. (Hérité de Object.)
	GetLock(Object, LockManager.LockType, Int64)	Obtenez un verrou.
	GetLock(ILockName, LockManager.LockType, Int64)	Obtenez un verrou nommé.
	GetType	Obtient le Type de l'instance actuelle. (Hérité de Object.)
	HasLocks	Renvoie True si ce requestId possède des verrous
	Lock(Object, Int64)	Obtenez un verrou de moniteur de feuille pour un objet donné.
	Lock(Object, LockManager.LockType, Int64)	Obtenez un verrou du moniteur d'objets.
	Lock(ILockName, LockManager.LockType, Int64)	Obtenez un verrou nommé.
	MemberwiseClone	Crée une copie superficielle de l'objet Object actuel. (Hérité de Object.)
	ReleaseAnyLock	En relâchez le verrou le plus imbriqué d'un type donné et verrouiller 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)	Teste si ce thread détient déjà un verrou.
	TestLock(String, LockManager.LockType, Int64)	Teste 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)	Obtenez un verrou nommé

Début

Notes

Le magasin managée pratique la manière d'éviter d'interblocage. Tout le verrouillage doit utiliser des verrous de LockManager. Chaque verrou est assigné un niveau (une position dans la hiérarchie verrouillante), et toute opération peut uniquement demander les verrous qui se trouvent plus haut dans la hiérarchie que tout verrou actuellement maintenu.

LockManager prend en charge le concept « nommé des verrous », par exemple lorsque nous devons verrouiller une certaine sécurité pour laquelle nous ne pouvons pas utiliser un objet stable dans la mémoire, mais avons un seul nom de cette entité. Les exemples sont boîte aux caractères alphabétiques et base de données. Tout objet associé à la boîte des lettres ou la base de données peut provenir et passer, tout ce que nous avons la plage de produits de cette entité est son nom, tel qu'une base de données GUID pour une base de données ou un nombre de boîte à des lettres pour une boîte à des lettres. Nous prenons en charge des verrous du moniteur et de verrous en lecture-écriture de verrous nommés.

LockManager prend également en charge « objet ordinaire verrous », lorsque nous devons verrouiller une instance d'objet particulière en mémoire. Seuls les verrous du moniteur sont actuellement pris en charge pour les verrouillages d'objet, c'est-à-dire le même mécanisme de verrouillage que l'instruction utilisée de « verrouillage » C#. Contrairement à l'instruction de « verrouillage », le verrou d'objet de LockManager participe entièrement à une hiérarchie verrouillante Par conséquent, nous pouvons les vérifier sont utilisés dans un ordre correct.

Un cas particulier de « verrouillage d'objet » est « un verrou d'objet de feuille ». Il ne faut pas spécifier le verrou de niveau pour ce verrou - supposée soit toujours un verrou plus imbriqué et aucun verrouillage ne peut être pris en maintenant ce verrou de feuille.

« A nommé des verrous » sont implémentés en allouant dynamiquement un objet de verrouillage pour chaque nom unique, et en les stockant dans un dictionnaire global. De ce fait l'accès à un verrou nommé requiert de nom de rechercher des dictionnaires pour rechercher un objet de verrouillage correspondant. Le dictionnaire d'objets lock si lui-même est verrouillé pendant que vous exécutez une telle correspondance. Tout compliquent les verrous nommés potentiellement plus chers que les verrous ordinaires, en raison de frais supplémentaires de verrouiller le dictionnaire et une recherche les dictionnaires. Nous utilisons deux techniques de réduire ce coût : (1) partitionnement le dictionnaire d'objet de verrouillage, pour réduire les conflits de verrouillage global de dictionnaire, et (2) fournissant l'appelant la fonction de mise la référence nommée d'objet de verrouillage et de contourner en cache rechercher des dictionnaires le plus souvent. Notez que seul partitionner s'avère car il ne permet pas beaucoup avec relativement des verrous de très portée, tels qu'un verrou de base de données ; par exemple, lorsque tout le monde souhaite entrer le même verrou partagé.

Il existe potentiellement nombre illimité d'uniques noms de verrouillage. Par conséquent, le nombre d'objets lock nommés que nous pouvons potentiellement les créer est également illimité. Étant donné que les références aux objets lock nommés sont stockées dans un dictionnaire global, ces objets peuvent jamais être automatiquement récupérés par le garbage collector. Par conséquent nous souhaitons pouvoir nettoyer les objets lock nommés qui ne sont pas régulièrement utilisés. Pour prendre en charge le nettoyage thread-safe des objets lock nommés, ces objets refcounted. Chaque verrou pris sur un objet de verrouillage nommé requiert faire « addrefed » un tel objet, la référence doit être récupéré après que le verrou soit libéré. La logique de nettoyage vérifie que l'objet n'est pas actuellement référencé avant de la supprimer du dictionnaire. Une fois un objet de verrouillage nommé suppression d'un dictionnaire, il est marqué comme supprimé et ne peut pas addrefed plus. Une tentative de verrouiller le même nom la fois suivante entraîne allouer un nouvel objet de verrouillage nommé portant le même nom et l'ajouter à un dictionnaire. En effet est OK pour mettre en cache des références nommées périmées d'objets lock par un appelant - une telle référence périmée est détectée et mise à jour lors que nous essayons de la verrouiller et d'allouer un nouvel objet de verrouillage.

Nous utilisons un heuristiques de temps simple pour nettoyer les objets lock inutilisés. Dans chaque version de verrou nommée par N nous appelle permettent si un temps d'exécuter le nettoyage, puis examinez le dictionnaire et collectent tous les objets non référencé qui ne sont pas utilisés récemment. Puis nous tentons de suppression chaque objet de ce type et de supprimer la référence d'un dictionnaire. Le nettoyage est par partition de dictionnaire, afin que nous ne deviez pas verrouiller d'autres partitions lorsque nous exécutons le nettoyage pour toute partition données.

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