SPB-Verbindungssperren

Verbindungssperren sind nützlich, damit zwei Clients den Zugriff auf ein Zielperipheriegerät auf einem einfachen Peripheriebus (SPB) freigeben können. Beide Clients können logische Verbindungen mit demselben Zielgerät öffnen und die Verbindungssperre verwenden, wenn ein Client exklusiven Zugriff auf das Gerät benötigt, um eine Reihe von E/A-Vorgängen auszuführen. Wenn ein Client die Verbindungssperre hält, werden Anforderungen des zweiten Clients, auf das Gerät zuzugreifen, automatisch zurückgestellt, bis der erste Client die Sperre loslässt.

Ein Client verwendet die IOCTL_SPB_LOCK_CONNECTION und IOCTL_SPB_UNLOCK_CONNECTION Anforderungen zum Abrufen und Freigeben der Verbindungssperre auf einem Zielgerät auf einem SPB. Ein Client sendet diese I/O-Steuerelementanforderungen (IOCTL) an das Dateiobjekt für das Gerät.

Der Treiber für ein MIT SPB verbundenes Peripheriegerät ist in der Regel entweder ein User-Mode Driver Framework (UMDF)-Treiber oder Kernel-Mode Driver Framework (KMDF)-Treiber. Um eine IOCTL-Anforderung an ein SPB-verbundenes Peripheriegerät zu senden, ruft ein UMDF-Treiber eine Methode wie IWDFIoRequest::Send auf. Ein KMDF-Treiber ruft eine Methode wie WdfIoTargetSendIoctlSynchronously auf.

In der Regel sind Verbindungssperren nicht erforderlich. Die meisten Clienttreiber haben immer exklusiven Zugriff auf ein Zielgerät auf einem SPB. Eine Verbindungssperre ist nur in dem relativ seltenen Fall erforderlich, in dem zwei Clients Zugriff auf dasselbe Zielgerät teilen müssen, und manchmal ein oder beide Clients exklusiven Zugriff auf das Gerät für eine Abfolge von E/A-Operationen benötigen.

Standardmäßig wird, wenn zwei Clients eine Zielvorrichtung gemeinsam nutzen, die SPB-Framework-Erweiterung (SpbCx) die E/A-Anfragen für das Gerät entsprechend der Reihenfolge, in der sie in der SpbCx-Anforderungswarteschlange ankommen, abgewickelt. Die Verbindungssperre setzt die Standardreihenfolge von Anforderungen außer Kraft. Nachdem ein Client die Verbindungssperre abgerufen hat, hält SpbCx E/A-Anforderungen zurück, die er vom zweiten Client empfängt, bis der erste Client die Sperre loslässt.

In der aktuellen Implementierung von SpbCx dient die primäre Verwendung von Verbindungssicherung dazu, dem Clienttreiber eines Zielgeräts zu ermöglichen, den Zugriff auf das Gerät mit dem ACPI-Treiber Acpi.syszu teilen. Acpi.sys ist ein vom System bereitgestellter Treiber, der bestimmte Kernressourcengeräte im Namen der ACPI-Firmware für die Hardwareplattform verwaltet. Beispielsweise kann eine Plattform, die ein System auf einem Chip (SoC) verwendet, auch eine integrierte Schaltung zur Stromversorgung (Power Management Integrated Circuit, PMIC) enthalten, auf die sowohl Acpi.sys als auch ein Clienttreiber zugreifen.

Ein Clienttreiber ist dafür verantwortlich, zu bestimmen, ob eine Verbindungssperre für E/A-Vorgänge erforderlich ist, die exklusiven Zugriff auf ein Zielgerät erfordern. Wenn ein Treiber Verbindungssperren in einigen Hardwareplattformen oder Plattformkonfigurationen erfordert, aber nicht in anderen, muss der Treiberentwickler und Plattformentwickler sich mit einem treiberspezifischen Mechanismus einverstanden erklären, um festzustellen, wann Verbindungssperren verwendet werden sollen. In der Regel sind Informationen darüber, ob Verbindungssperren verwendet werden sollen, in der Plattformfirmware enthalten. Der vom Anbieter definierte Informationsblock im ACPI-Ressourcendeskriptor für das Gerät kann z. B. ein Flagbit enthalten, um anzugeben, ob der Treiber das Gerät mit Acpi.systeilt.

Beispiel für die Verbindungssperre

Eine typische Verwendung einer Verbindungssperre besteht darin, einen atomaren Lese-Änderungs-Schreibvorgang zu implementieren. Wenn zwei Clients den Zugriff auf dasselbe Zielgerät auf einem einfachen Peripheriebus (SPB) gemeinsam nutzen, kann jeder Client die Verbindungssperre verwenden, um einen Lesevorgang und einen Schreibvorgang in einen einzelnen, atomaren Lese-Änderung-Schreibvorgang zusammenzuführen. Die Verbindungssperre verhindert, dass der andere Client zwischen lese- und schreibvorgängen auf das Zielgerät zugreift.

In der folgenden Liste werden die Reihe von E/A-Anforderungen beschrieben, die ein Client möglicherweise an ein SPB-verbundenes Zielgerät sendet, um einen Lese-Änderungs-Schreibvorgang auf dem Gerät auszuführen.

1. IOCTL_SPB_LOCK_CONNECTION – Abrufen der Verbindungssperre auf dem Zielgerät.
2. IRP_MJ_READ – Lesen Sie einen Datenblock aus der Geräteadresse, damit der Client die Daten interpretieren und ändern kann.
3. IRP_MJ_WRITE – Schreiben Sie den geänderten Datenblock an die Geräteadresse.
4. IOCTL_SPB_UNLOCK_CONNECTION – Lassen Sie die Verbindungssperre auf dem Zielgerät los.

Die obige Liste eignet sich möglicherweise für ein einfaches Gerät, das eine einzelne Gerätefunktion implementiert.

Ein komplexeres Gerät kann jedoch mehrere Gerätefunktionen implementieren. Dieses Gerät kann ein Funktionsadressregister enthalten, das der Client zu Beginn einer Datenübertragung lädt. Für dieses Gerät kann eine IOCTL_SPB_EXECUTE_SEQUENCE-Anforderung das Laden des Funktionsadressenregisters und die darauf folgende Datenübertragung in einem einzigen atomaren Busbetrieb kombinieren. Weitere Informationen finden Sie in der Beschreibung des Beispielgeräts I²C in Atomic Bus Operations.

Vergleich mit Controllersperren

Ein Client verwendet eine Verbindungssperre, um exklusiven Zugriff auf ein Zielgerät zu erhalten, die Verbindungssperre verhindert jedoch keine Datenübertragungen an oder von anderen Geräten im Bus.

Um eine Reihe von Datenübertragungen als Atombusbetrieb durchzuführen, verwenden Clients in der Regel eine IOCTL_SPB_EXECUTE_SEQUENCE Anforderung. Eine weniger häufige Möglichkeit zum Ausführen eines Atombusbetriebs besteht darin, eine Controllersperre zu verwenden. Ein Client sendet IOCTL_SPB_LOCK_CONTROLLER und IOCTL_SPB_UNLOCK_CONTROLLER Anforderungen zum Abrufen und Freigeben einer Controllersperre.

Controllersperren unterscheiden sich von Verbindungssperren. Eine Controllersperre ermöglicht eine Abfolge von E/A-Übertragungen zu und von einem Zielgerät auf dem Bus, die als ein einzelner, atomarer Busvorgang ausgeführt werden. Während die Controllersperre wirksam ist, werden Übertragungen an oder von anderen Geräten auf dem Bus zurückgestellt, bis die Controllersperre losgelassen wird. Weitere Informationen finden Sie unter Atomic Bus Operations.

Möglicherweise muss ein Client sowohl eine Verbindungssperre als auch eine Controllersperre sichern, bevor eine Reihe von E/A-Vorgängen auf einem Zielgerät ausgeführt wird. Die Verbindungssperre verhindert, dass ein zweiter Client, der zugriff auf dasselbe Zielgerät teilt, E/A-Vorgänge auf dem Gerät ausführt, und die Controllersperre verhindert, dass Clients für andere Geräte auf dem Bus E/A-Vorgänge auf diesen anderen Geräten ausführen. (E/A-Vorgänge, die daran gehindert werden, während diese Sperren gehalten werden, werden einfach zurückgestellt, bis die Sperren freigegeben werden.)

Wenn ein Client sowohl eine Verbindungssperre als auch eine Controllersperre für ein Zielgerät auf einem SPB erhält, muss der Client die Verbindungssperre abrufen, bevor er die Controllersperre erhält und die Controllersperre freigeben muss, bevor die Verbindungssperre losgelassen wird. Nachdem ein Client eine Verbindungssperre erworben hat, kann der Client bei Bedarf die Controllersperre so oft abrufen und freigeben, wie es erforderlich ist, bevor der Client die Verbindungssperre loslässt.

Geschachtelte Käufe einer Verbindungssperre sind illegal. Nachdem ein Client eine Verbindungssperre erworben hat, darf der Client nicht versuchen, die Sperre erneut zu erwerben, bevor er die Sperre loslässt. Ebenso sind geschachtelte Käufe einer Controllersperre nicht zulässig.