Fonction FltInitializePushLock (fltkernel.h)

  • Article

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 sizeof(EX_PUSH_LOCK), pour que la variable de verrouillage push soit initialisée. Le stockage doit être aligné sur 4 octets sur les plateformes 32 bits et sur 8 octets sur les plateformes 64 bits.

Valeur de retour

None

Remarques

Les verrous push sont rarement un bon choix pour les minifiltres du système de fichiers. Comme décrit ci-dessous, certaines de leurs caractéristiques peuvent être incompatibles avec la nature intrinsèque de la réinscription des systèmes de fichiers.

Les verrous push sont similaires aux structures ERESOURCE (également appelées « ressources ») des manières suivantes :

  • 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 : c’est-à-dire que ses membres sont réservés à l’utilisation du système.
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 équitable pour tous les threads. S’il existe un niveau élevé de contention de verrouillage exclusif, il n’y a aucune garantie quant à l’ordre dans lequel les threads bénéficieront d’un 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 qu’ExIsResourceAcquiredExclusiveLite pour déterminer si le thread actuel dispose d’un accès exclusif à la ressource.)
  • Pour la même raison, 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, et donc diagnostiquer les interblocages. (Les utilisateurs des structures ERESOURCE peuvent utiliser l’extension !locks dans kd ou windbg pour le savoir.)
  • Il n’existe aucune prise en charge du vérificateur de pilotes pour faciliter le diagnostic précoce des interblocages via les verrous push.
  • Les verrous push exclusifs ne peuvent pas être acquis de manière récursive.
Les verrous push offrent les avantages suivants par rapport aux 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, ERESOURCE est généralement la solution la plus robuste et la plus gérable au problème de synchronisation en lecture-écriture.

Pour acquérir un verrou push pour un accès exclusif, appelez FltAcquirePushLockExclusive.

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

Pour libérer un verrou push, appelez FltReleasePushLock.

Pour supprimer un verrou push, appelez FltDeletePushLock.

Configuration requise

Condition requise Valeur
Client minimal pris en charge Cette routine est disponible sur Microsoft Windows XP SP2, Microsoft Windows Server 2003 SP1 et versions ultérieures.
Plateforme cible Universal
En-tête fltkernel.h (inclure Fltkernel.h)
Bibliothèque FltMgr.lib
DLL Fltmgr.sys
IRQL <= APC_LEVEL

Voir aussi

ExIsResourceAcquiredExclusiveLite

FltAcquirePushLockExclusive

FltAcquirePushLockShared

FltDeletePushLock

FltReleasePushLock