Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
Gambar berikut mengilustrasikan penggunaan timer pemberitahuan untuk menyiapkan interval batas waktu untuk operasi lalu menunggu sementara rutinitas driver lain memproses permintaan I/O.
Seperti yang ditunjukkan oleh gambar sebelumnya, driver harus menyediakan penyimpanan untuk objek timer, yang harus diinisialisasi dengan panggilan ke KeInitializeTimer dengan pointer ke penyimpanan ini. Driver biasanya melakukan panggilan ini dari rutinitas AddDevice-nya .
Dalam konteks utas tertentu, seperti utas yang dibuat driver atau utas yang meminta operasi I/O sinkron, driver dapat menunggu objek timer-nya seperti yang ditunjukkan pada gambar sebelumnya:
Utas memanggil KeSetTimer dengan penunjuk ke objek timer dan nilai DueTime tertentu, yang dinyatakan dalam satuan 100 nanodetik. Nilai positif untuk DueTime menentukan waktu absolut di mana objek timer harus dihapus dari antrean timer kernel dan diatur ke status Sinyal. Nilai negatif untuk DueTime menentukan interval relatif terhadap waktu sistem saat ini.
Perhatikan bahwa utas (atau rutinitas driver yang berjalan dalam utas sistem) melewati penunjuk NULL untuk objek DPC (ditunjukkan sebelumnya dalam gambar yang mengilustrasikan menggunakan objek timer dan DPC untuk rutinitas CustomTimerDpc) ketika memanggil KeSetTimer jika menunggu pada objek timer alih-alih mengantre rutinitas CustomTimerDpc .
Utas memanggil KeWaitForSingleObject dengan penunjuk ke objek timer, yang menempatkan utas ke dalam status tunggu saat objek timer berada dalam antrean timer kernel.
DueTime yang diberikan kedaluwarsa.
Kernel menghapus antrean objek timer, mengaturnya ke status Sinyal, dan mengubah status utas dari menunggu menjadi siap.
Kernel mengirimkan utas untuk dieksekusi segera setelah prosesor tersedia: yaitu, tidak ada utas lain dengan prioritas yang lebih tinggi saat ini dalam keadaan siap dan tidak ada rutinitas mode kernel untuk dijalankan pada IRQL yang lebih tinggi.
Rutinitas driver yang berjalan di IRQL >= DISPATCH_LEVEL dapat kehabisan waktu permintaan dengan menggunakan objek timer dengan objek DPC terkait untuk mengantre rutinitas CustomTimerDpc yang disediakan driver. Hanya rutinitas driver yang berjalan dalam konteks utas nonarbitrer yang dapat menunggu interval bukan nol pada objek timer, seperti yang ditunjukkan pada gambar sebelumnya.
Seperti setiap utas lainnya, utas yang dibuat driver diwakili oleh objek utas kernel, yang juga merupakan objek dispatcher. Akibatnya, driver tidak perlu memiliki utas yang dibuat driver menggunakan objek timer untuk secara sukarela menempatkan dirinya ke dalam status tunggu untuk interval tertentu. Sebagai gantinya, utas dapat memanggil KeDelayExecutionThread dengan interval yang disediakan penelepon. Untuk informasi selengkapnya tentang teknik ini, lihat Polling Perangkat.
Rutinitas DriverEntry, Reinitialize, dan Unload juga berjalan dalam konteks utas sistem, sehingga driver dapat memanggil KeWaitForSingleObject dengan objek timer yang diinisialisasi driver atau KeDelayExecutionThread saat mereka menginisialisasi atau membongkar. Driver perangkat dapat memanggil KeStallExecutionProcessor untuk interval yang sangat singkat (sebaiknya sesuatu yang kurang dari 50 mikro detik) jika harus menunggu perangkat memperbarui status selama inisialisasinya.
Namun, driver tingkat yang lebih tinggi umumnya menggunakan mekanisme sinkronisasi lain dalam DriverEntry mereka dan menginisialisasi ulang rutinitas alih-alih menggunakan objek timer. Driver tingkat yang lebih tinggi harus selalu dirancang untuk melapisi diri mereka sendiri melalui driver tingkat bawah dari jenis atau jenis perangkat tertentu. Oleh karena itu, driver tingkat yang lebih tinggi cenderung menjadi lambat untuk dimuat jika menunggu pada objek timer atau memanggil KeDelayExecutionThread karena driver seperti itu harus menunggu interval yang cukup lama untuk mengakomodasi perangkat paling lambat yang mendukungnya. Perhatikan juga bahwa interval "aman" tetapi minimum untuk penantian seperti itu sangat sulit untuk ditentukan.
Demikian pula, driver PnP tidak boleh menunggu tindakan lain terjadi, tetapi sebaliknya harus menggunakan mekanisme pemberitahuan manajer PnP.