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호출합니다.

공유 액세스에 대한 푸시 잠금을 가져오려면 FltAcquirePushLockExclusive호출합니다.

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

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

exIsResourceAcquiredExclusiveLite