Obiekty semaforów

Każdy sterownik może używać obiektu semafora do synchronizowania operacji między wątkami utworzonymi przez sterownik a innymi procedurami sterowników. Na przykład dedykowany wątek sterownika może umieścić się w stanie oczekiwania, gdy nie ma zaległych żądań we/wy dla sterownika, a procedury wysyłania kierowcy mogą ustawić semafor na stan Sygnał tuż po kolejce IRP.

Procedury wysyłania sterowników najwyższego poziomu, które są uruchamiane w kontekście wątku żądającego operacji we/wy, mogą używać semafora do ochrony zasobu udostępnionego wśród procedur wysyłania. Procedury wysyłania sterowników niższego poziomu dla synchronicznych operacji we/wy mogą również używać semafora do ochrony zasobu udostępnionego między tym podzestawem procedur wysyłania lub z wątkiem utworzonym przez sterownik.

Każdy sterownik używający obiektu semafora musi wywołać KeInitializeSemaphore przed oczekiwaniem na semafor lub zwalnia go. Na poniższej ilustracji pokazano, jak sterownik z wątkiem może używać obiektu semafora.

Jak pokazano na poprzedniej ilustracji, taki sterownik musi zapewnić magazyn dla obiektu semafora, który powinien być rezydentem. Sterownik może używać rozszerzenia urządzenia obiektu urządzenia utworzonego przez sterownik, rozszerzenia kontrolera, jeśli używa obiektu kontrolera lub niestronnej puli przydzielonej przez sterownik.

Gdy sterownik AddDevice rutynowych wywołań KeInitializeSemaphore, musi przekazać wskaźnik do magazynu rezydentnego kierowcy dla obiektu semafora. Ponadto obiekt wywołujący musi określić liczba dla obiektu semafora, jak pokazano na poprzedniej ilustracji, który określa jego stan początkowy (niezerowy dla sygnalizatora).

Obiekt wywołujący musi również określić limit dla semafora, który może być jednym z następujących elementów:

• limit = 1

  Gdy ten semafor jest ustawiony na stan Sygnał, pojedynczy wątek czeka na ustawienie semafora na stan Sygnał staje się uprawniony do wykonania i może uzyskać dostęp do dowolnego zasobu chronionego przez semafor.

  Ten typ semafora jest również nazywany semafor binarny, ponieważ wątek ma lub nie ma wyłącznego dostępu do zasobu chronionego semaforem.

• limit > 1

  Gdy ten semafor jest ustawiony na stan Sygnał, niektóre wątki oczekujące na ustawienie obiektu semafora na stan Sygnał stają się uprawnione do wykonania i mogą uzyskiwać dostęp do dowolnego zasobu chronionego przez semafor.

  Ten typ semafora jest nazywany liczenie semafora, ponieważ rutyna ustawia semafora na stan Signaled określa również, ile wątków oczekujących może zmienić ich stany od oczekiwania na gotowe. Liczba takich wątków oczekujących może być limit ustawiony podczas inicjowania semafora lub pewnej liczby mniejszej niż ta wstępnie ustawiona Limit.

Niewiele sterowników urządzeń lub pośrednich ma jeden wątek utworzony przez sterownik; nawet mniej ma zestaw wątków, które mogą czekać na uzyskanie lub zwolnienie semafora. Niewiele sterowników dostarczonych przez system używa obiektów semaforów, a z tych, które robią, nawet mniej używa semaforu binarnego. Chociaż semafor binarny może wydawać się podobny do obiektu mutex, semafor binarny nie zapewnia wbudowanej ochrony przed zakleszczeniami, które obiekt mutex ma dla wątków systemowych uruchomionych na maszynach SMP.

Po załadowaniu sterownika z zainicjowanym semaforem można zsynchronizować operacje na semaforze, który chroni udostępniony zasób. Na przykład sterownik z dedykowanym wątkiem urządzenia, który zarządza kolejkowaniem irps, takich jak sterownik kontrolera dyskietki systemowej, może synchronizować kolejkowanie IRP na semaforze, jak pokazano na poprzedniej ilustracji:

1. Wątek wywołuje KeWaitForSingleObject ze wskaźnikiem do magazynu dostarczonego przez sterownik dla zainicjowanego obiektu semafora, aby umieścić się w stanie oczekiwania.

2. Ip zaczynają pojawiać się, które wymagają operacji we/wy urządzenia. Procedury wysyłania kierowcy wstawiają każdy taki protokół IRP do zablokowania kolejki w ramach sterowania blokadą spin-lock i wywołają KeReleaseSemaphore z wskaźnikiem do obiektu semafora, zwiększenie priorytetu określonego przez sterownik dla wątku (przyrostu, jak pokazano na poprzedniej ilustracji), korekta z 1, która jest dodawana do liczby semaforów, gdy każdy protokół IRP jest w kolejce, i wartość logiczna Wait ustawiona na wartość FALSE. Liczba semaforów niezerowych ustawia obiekt semafora na stan Sygnał, zmieniając w ten sposób stan oczekującego wątku na gotowy.

3. Jądro wysyła wątek do wykonania zaraz po udostępnieniu procesora: oznacza to, że żaden inny wątek o wyższym priorytcie jest obecnie w stanie gotowości i nie ma procedur trybu jądra do uruchomienia w wyższym środowisku IRQL.

   Wątek usuwa protokół IRP z połączonej kolejki w ramach sterowania blokadą spin-lock, przekazuje go do innych procedur sterownika w celu dalszego przetwarzania i wywołuje KeWaitForSingleObject ponownie. Jeśli semafor jest nadal ustawiony na stan Signaled (czyli liczba pozostaje niezerowa, co wskazuje, że więcej irps znajduje się w kolejce zakłęconej przez sterownik), jądro ponownie zmienia stan wątku z oczekiwania na gotowość.

   Używając semafora zliczania w ten sposób, taki wątek sterownika "wie" istnieje IRP, który ma zostać usunięty z kolejki zakleszczonej za każdym razem, gdy ten wątek jest uruchamiany.

Aby uzyskać informacje specyficzne dla zarządzania środowiskiem IRQL podczas wywoływania KeReleaseSemaphore, zobacz sekcję Uwagi KeReleaseSemaphore.

Każda standardowa procedura sterownika, która działa w irQL większym niż PASSIVE_LEVEL nie może czekać na interwał niezerowy na żadnych obiektach dyspozytora bez wyłączania systemu; Aby uzyskać szczegółowe informacje, zobacz Obiektów dyspozytora jądra. Jednak taka rutyna może wywołać KeReleaseSemaphore podczas uruchamiania w środowisku IRQL mniejszym lub równym DISPATCH_LEVEL.

Aby zapoznać się z podsumowaniem list IRQLs, w których są uruchamiane standardowe procedury sterowników, zobacz Zarządzanie priorytetami sprzętu. Aby zapoznać się z wymaganiami środowiska IRQL określonymi procedurami pomocy technicznej, zobacz stronę referencyjną procedury.