Uso Power-Managed code di I/O

Quando un driver crea una coda di I/O, può specificare se la coda è gestita dall'alimentazione. Quando le richieste di I/O sono disponibili in una coda gestita dall'alimentazione, il framework recapita le richieste al driver solo se il dispositivo è in stato funzionante (D0). Il framework non consente al dispositivo di lasciare lo stato di lavoro fino a quando tutte le richieste di I/O recapitate dal framework dalla coda gestita dall'alimentazione al driver non sono state completate, annullate o posticipate.

Per altre informazioni sulle code di I/O con risparmio energia, vedere Power Management per le code di I/O.

Funzioni di callback per Power-Managed code

Se il driver usa code di I/O gestite dall'alimentazione, può fornire due funzioni di callback aggiuntive:

EvtIoStop
La funzione di callback EvtIoStop interrompe l'elaborazione di una richiesta di I/O specificata. Quando il dispositivo lascia lo stato di lavoro (D0) o viene rimosso, il framework chiama una volta la funzione di callback EvtIoStop di una coda di I/O per ogni richiesta di I/O non completata dal driver, incluse le richieste di proprietà del driver e quelle inoltrate a una destinazione di I/O.

EvtIoResume
La funzione di callback EvtIoResume riprende l'elaborazione di una richiesta di I/O arrestata in precedenza. Il framework chiama la funzione di callback EvtIoResume di una coda di I/O quando riprende a recapitare le richieste di I/O al driver dalla coda, dopo che il dispositivo è tornato allo stato di lavoro.

Ogni volta che il framework chiama la funzione di callback EvtIoStop di un driver, la funzione in genere completa o annulla la richiesta di I/O o chiama WdfRequestStopAcknowledge per restituire la proprietà della richiesta al framework.

Anche se questa operazione è facoltativa, è in genere necessario fornire una funzione di callback EvtIoStop per una coda gestita da power. Fornendo EvtIoStop, il driver può aiutare a ridurre il tempo trascorso prima che il dispositivo e possibilmente il sistema entri in uno stato a basso consumo.

Se non si specifica EvtIoStop per una coda gestita dall'alimentazione, il framework attende fino al completamento di tutte le richieste recapitate dalla coda gestita dall'alimentazione al driver prima di spostare il dispositivo (o il sistema) a uno stato di alimentazione inferiore o rimuovere il dispositivo. Potenzialmente, questa inazione può impedire a un sistema di entrare nello stato di ibernazione o a un altro stato di alimentazione del sistema basso. In casi estremi, può causare l'arresto anomalo del sistema con codice di controllo dei bug 9F.

Se il driver non inoltra le richieste a una destinazione di I/O e non contiene richieste per un tempo indeterminato, è possibile omettere in modo sicuro EvtIoStop per una coda gestita dall'alimentazione.

Attesa di oggetti Dispatcher

In generale, i driver devono usare solo oggetti dispatcher come meccanismi di sincronizzazione all'interno di un contesto di thread non arbitrario.

Poiché i gestori richieste vengono eseguiti in un contesto di thread arbitrario, un gestore richieste per una coda gestita da power non deve attendere l'impostazione degli oggetti dispatcher del kernel. In questo modo potrebbe verificarsi un deadlock.

Per altre informazioni su quando un driver può attendere gli oggetti dispatcher e su cosa fare quando non è possibile, vedere Introduzione agli oggetti Dispatcher del kernel.