Partager via


FltInitializePushLock, fonction (fltkernel.h)

La routine FltInitializePushLock initialise une variable de verrouillage Push.

Syntaxe

VOID FLTAPI FltInitializePushLock(
  [out] PEX_PUSH_LOCK PushLock
);

Paramètres

[out] PushLock

Pointeur vers le stockage fourni par l’appelant, qui doit être au moins la valeur de sizeof(EX_PUSH_LOCK), pour que la variable de verrou push soit initialisée. Le stockage doit être aligné sur 4 octets sur des plateformes 32 bits et alignés sur des plateformes 64 bits.

Valeur de retour

Aucun

Remarques

Un verrou Push est une primitive de synchronisation utilisée pour gérer l’accès aux ressources partagées par plusieurs threads. Les verrous push sont similaires à structures ERESOURCE (également appelées « ressources ») de la manière suivante :

  • Les verrous push peuvent être utilisés pour la synchronisation par un ensemble de threads.

  • Les verrous push peuvent être acquis pour un accès partagé ou exclusif.

  • Bien que l’appelant fournisse le stockage de la variable de verrouillage Push, la structure EX_PUSH_LOCK est opaque : autrement dit, ses membres sont réservés à l’utilisation du système.

Les verrous push peuvent ne pas être le bon choix pour les mini-filtres du système de fichiers, car certaines de leurs caractéristiques peuvent être incompatibles avec la nature intrinsèquement entrante des systèmes de fichiers.

Les verrous push présentent les inconvénients suivants par rapport aux structures ERESOURCE :

  • L’algorithme d’octroi d’un accès exclusif n’est pas juste pour tous les threads. S’il existe un niveau élevé de contention de verrouillage exclusif, il n’existe aucune garantie sur l’ordre dans lequel les threads seront accordés à l’accès exclusif.

  • Il n’existe aucune routine de prise en charge pour déterminer le propriétaire actuel d’un verrou push au moment de l’exécution. Les utilisateurs de structures ERESOURCE peuvent appeler des routines telles que ExIsResourceAcquiredExclusiveLite pour déterminer si le thread actuel a un accès exclusif à la ressource.

  • Il n’existe aucune extension de prise en charge pour déterminer le propriétaire actuel d’un verrou push au moment du débogage afin de diagnostiquer les blocages. Les utilisateurs de structures ERESOURCE peuvent utiliser l’extension !locks dans kd ou windbg pour déterminer le propriétaire actuel.

  • Il n’existe aucune prise en charge du vérificateur de pilote pour faciliter le diagnostic précoce des interblocages par le biais de verrous push.

  • Les verrous push exclusifs ne peuvent pas être acquis de manière récursive.

Les verrous push offrent les avantages suivants sur les structures ERESOURCE :

  • Lorsque les verrous push sont principalement acquis pour l’accès partagé, ils sont plus efficaces que les structures ERESOURCE.

  • Le stockage des verrous Push peut être alloué à partir d’un pool paginé ou non paginé. Les structures ERESOURCE doivent être allouées uniquement à partir d’un pool non paginé.

  • EX_PUSH_LOCK structures sont beaucoup plus petites que les structures ERESOURCE.

À moins que l’un de ces avantages ne soit convaincant, une ERESOURCE est généralement la solution plus robuste et plus facile à gérer pour le problème de synchronisation en lecture/écriture.

Pour acquérir un verrou Push pour un accès exclusif, appelezFltAcquirePushLockExclusive.

Pour acquérir un verrou Push pour l’accès partagé, appelez FltAcquirePushLockExclusive.

Pour libérer un verrou Push, appelez FltReleasePushLock.

Pour supprimer un verrou Push, appelez FltDeletePushLock.

Exigences

Exigence Valeur
client minimum pris en charge Windows XP SP2 Microsoft
serveur minimum pris en charge Windows Server 2003 SP1
plateforme cible Universel
d’en-tête fltkernel.h (include Fltkernel.h)
bibliothèque FltMgr.lib
DLL Fltmgr.sys
IRQL <= APC_LEVEL

Voir aussi

ExIsResourceAcquiredExclusiveLite

FltAcquirePushLockExclusive

FltAcquirePushLockShared

FltDeletePushLock

FltReleasePushLock