Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Per disabilitare un oggetto timer impostato in precedenza, un driver chiama KeCancelTimer. Questa routine rimuove l'oggetto del timer dalla coda del timer del sistema. In genere, l'oggetto timer non è impostato sullo stato segnalato e la routine CustomTimerDpc non viene accodata per l'esecuzione. Tuttavia, se il timer sta per scadere quando viene chiamato KeCancelTimer , la scadenza potrebbe verificarsi prima che KeCancelTimer abbia la possibilità di accedere alla coda temporale, nel qual caso si verificherà la segnalazione e l'accodamento DPC.
Il richiamo di KeSetTimer o KeSetTimerEx, con puntatori Timer e Dpc specificati in precedenza, prima della scadenza dell'intervallo specificato in precedenza, ha gli effetti seguenti:
Il kernel rimuove l'oggetto timer dalla coda timer, senza impostare l'oggetto sullo stato segnalato o accodando la routine CustomTimerDpc .
Il kernel reinsere l'oggetto timer nella coda timer, usando il nuovo valore DueTime .
L'uso dello stesso oggetto timer per scopi diversi può causare race condition o gravi errori del driver. Si supponga, ad esempio, che un driver specifichi un singolo oggetto timer per configurare una chiamata a una routine CustomTimerDpc e per configurare le attese in un thread dedicato al driver. Ogni volta che il thread dedicato al driver chiama KeSetTimer, KeSetTimerEx o KeCancelTimer per l'oggetto timer comune, il thread annulla le chiamate alla routine CustomTimerDpc , se l'oggetto timer è già stato accodato per una chiamata CustomTimerDpc .
Se un driver dispone di routine CustomTimerDpc e attende anche gli oggetti timer in un contesto di thread non arbiverso, deve:
Non utilizzare mai un oggetto timer sensibile al contesto del thread in un contesto di thread non arbitrario, o viceversa.
Allocare un oggetto timer separato per ogni routine CustomTimerDpc . Ogni set di thread driver o routine driver chiamati in un contesto di thread non arbitrario deve avere un proprio set di oggetti timer "waitable".
Se si usa una routine CustomTimerDpc , scegliere con attenzione l'intervallo che il driver passa nelle chiamate a KeSetTimer o KeSetTimerEx. Considerare inoltre tutti i possibili effetti di una chiamata a KeCancelTimer con lo stesso oggetto timer di qualsiasi routine driver che effettua questa chiamata, in particolare sulle piattaforme SMP.
Tenere presente quanto segue sulle routine CustomTimerDpc :
È possibile accodare una sola istanza di un oggetto DPC che rappresenta una determinata routine DPC per l'esecuzione in un determinato momento.
Se una seconda routine driver chiama KeSetTimer o KeSetTimerEx per eseguire la stessa routine CustomTimerDpc prima della scadenza dell'intervallo specificato dal primo chiamante, la routine CustomTimerDpc viene eseguita solo dopo la scadenza dell'intervallo specificato dal secondo chiamante. In queste circostanze, CustomTimerDpc non esegue alcuna operazione per la quale la prima routine denominata KeSetTimer o KeSetTimerEx.
Per i driver che hanno routine CustomTimerDpc e usano timer periodici:
Un driver non può deallocare un timer periodico da una routine DPC. I driver possono deallocare solo timer nonperiodici da una routine DPC.
Considerare le linee guida di progettazione seguenti per i driver con routine CustomDpc e CustomTimerDpc :
Per evitare condizioni di gara, non passare mai lo stesso puntatore Dpc a KeSetTimer o KeSetTimerEx e KeInsertQueueDpc.
In altre parole, si supponga che la routine StartIo di un driver chiami KeSetTimer o KeSetTimerEx per accodare una routine CustomTimerDpc e che l'ISR del driver chiami keInsertQueueDpc simultaneamente da un altro processore con lo stesso puntatore Dpc . Tale routine DPC verrà eseguita quando IRQL in un processore scende al di sotto di DISPATCH_LEVEL o l'intervallo timer scade, a seconda del primo. Qualsiasi sia il primo, alcune operazioni essenziali per StartIo o ISR potrebbero essere semplicemente eliminate dalla routine DPC.
Inoltre, un DPC usato da due routine di driver standard con funzionalità molto diverse avrebbe caratteristiche di prestazioni inferiori rispetto alle routine CustomTimerDpc e CustomDpc separate. Il DPC dovrebbe determinare quali operazioni eseguire, a seconda delle condizioni che hanno causato il posizionamento in coda della routine StartIo o dell'ISR. Il test di queste condizioni nel DPC userebbe cicli di CPU aggiuntivi.