FltInitializePushLock 함수(fltkernel.h)

FltInitializePushLock 루틴은 푸시 잠금 변수를 초기화합니다.

구문

VOID FLTAPI FltInitializePushLock(
  [out] PEX_PUSH_LOCK PushLock
);

[out] PushLock

푸시 잠금 변수를 초기화하려면 최소한 sizeof(EX_PUSH_LOCK)의 값이어야 하는 호출자 제공 스토리지에 대한 포인터입니다. 스토리지는 32비트 플랫폼에서 4 바이트를 정렬하고 64비트 플랫폼에서 8 바이트를 정렬해야 합니다.

없음

푸시 잠금은 파일 시스템 미니필터에 적합하지 않습니다. 아래에 설명된 대로 일부 특성은 파일 시스템의 본질적으로 재입력 특성과 호환되지 않을 수 있습니다.

푸시 잠금은 다음과 같은 방법으로 ERESOURCE 구조 ("리소스"라고도 함)와 유사합니다.

푸시 잠금은 스레드 집합의 동기화에 사용할 수 있습니다.
공유 또는 배타적 액세스를 위해 푸시 잠금을 가져올 수 있습니다.
호출자가 푸시 잠금 변수에 대한 스토리지를 제공하지만 EX_PUSH_LOCK 구조는 불투명합니다. 즉, 해당 멤버는 시스템 사용을 위해 예약되어 있습니다.

푸시 잠금은 ERESOURCE 구조와 비교할 때 다음과 같은 단점이 있습니다.

배타적 액세스 권한을 부여하는 알고리즘은 모든 스레드에 공평하지 않습니다. 높은 수준의 배타적 잠금 경합이 있는 경우 스레드에 배타적 액세스 권한이 부여되는 순서에 대한 보장은 없습니다.
런타임에 푸시 잠금의 현재 소유자를 결정하기 위한 지원 루틴은 없습니다. (ERESOURCE 구조체의 사용자는 ExIsResourceAcquiredExclusiveLite 와 같은 루틴을 호출하여 현재 스레드가 리소스에 대한 단독 액세스 권한이 있는지 여부를 확인할 수 있습니다.)
같은 이유로 디버그 시 푸시 잠금의 현재 소유자를 결정하고 교착 상태를 진단하기 위한 지원 확장이 없습니다. (ERESOURCE 구조의 사용자는 kd 또는 windbg의 확장을 사용하여 !locks 이를 확인할 수 있습니다.)
푸시 잠금을 통해 교착 상태를 조기에 진단하는 데 도움이 되는 드라이버 검증 도구 지원은 없습니다.
단독 푸시 잠금은 재귀적으로 가져올 수 없습니다.

푸시 잠금은 ERESOURCE 구조에 비해 다음과 같은 이점을 제공합니다.

공유 액세스를 위해 푸시 잠금을 주로 획득하는 경우 ERESOURCE 구조보다 더 효율적입니다.
푸시 잠금에 대한 스토리지는 페이징된 풀 또는 비페이지 풀에서 할당할 수 있습니다. ERESOURCE 구조체는 페이지가 없는 풀에서만 할당해야 합니다.
EX_PUSH_LOCK 구조체는 ERESOURCE 구조체보다 훨씬 작습니다.

이러한 장점이 없다면 ERESOURCE는 일반적으로 읽기/쓰기 동기화 문제에 대한 보다 강력하고 유지 관리 가능한 솔루션입니다.

단독 액세스를 위한 푸시 잠금을 획득하려면 FltAcquirePushLockExclusive를 호출합니다.

공유 액세스에 대한 푸시 잠금을 획득하려면 FltAcquirePushLockShared를 호출합니다.

푸시 잠금을 해제하려면 FltReleasePushLock을 호출합니다.

푸시 잠금을 삭제하려면 FltDeletePushLock을 호출합니다.

요구 사항	값
지원되는 최소 클라이언트	이 루틴은 Microsoft Windows XP SP2, Microsoft Windows Server 2003 SP1 이상에서 사용할 수 있습니다.
대상 플랫폼	유니버설
헤더	fltkernel.h(Fltkernel.h 포함)
라이브러리	FltMgr.lib
DLL	Fltmgr.sys
IRQL	<= APC_LEVEL