Uso di 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 da energia, il framework recapita le richieste al driver solo se il dispositivo si trova nello stato di lavoro (D0). Il framework non consente al dispositivo di lasciare lo stato di lavoro fino a quando tutte le richieste di I/O che il framework ha recapitato dalla coda gestita dall'alimentazione al driver sono stati completati, annullati o posticipati.

Per altre informazioni sulle code di I/O gestite dall'alimentazione, vedere Power Management for I/O Queues(Gestione energia per le code di I/O).

Funzioni di callback per le code di Power-Managed

Se il driver usa code di I/O gestite da 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 funzione di callback EvtIoStop della coda di I/O una volta per ogni richiesta di I/O che il driver non è stato completato, incluse le richieste che il driver possiede e quelli che ha inoltrato 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 una funzione di callback evtIoResume della coda di I/O quando riprende a recapitare le richieste di I/O al driver dalla coda, dopo che il dispositivo ha restituito lo stato di funzionamento.

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

Durante questa operazione è facoltativo, è consigliabile fornire in generale una funzione di callback EvtIoStop per una coda gestita da energia. Fornendo EvtIoStop, il driver può aiutare a ridurre il tempo trascorso prima del dispositivo, e possibilmente il sistema, entra in uno stato di bassa potenza.

Se non si fornisce EvtIoStop per una coda gestita dall'alimentazione, il framework attende fino a quando tutte le richieste inviate dalla coda gestita dall'alimentazione al driver vengono completate prima di spostare il dispositivo (o il sistema) in uno stato di alimentazione inferiore o rimuovere il dispositivo. Potenzialmente, questa inazione può impedire a un sistema di immettere lo stato di ibernazione o un altro stato di alimentazione di sistema basso. In casi estremi, può causare l'arresto anomalo del sistema con il codice di controllo 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 da alimentazione.

Attesa di oggetti Dispatcher

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

Poiché i gestori delle richieste vengono eseguiti in un contesto di thread arbitrario, un gestore delle richieste per una coda gestita da energia non deve attendere che gli oggetti del dispatcher del kernel vengano impostati. In questo modo potrebbe verificarsi un deadlock.

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