Asynchronous Disk i/O muncul sebagai sinkron pada Windows NT, Windows 2000 dan Windows XP

I/O berkas pada Microsoft Windows NT, Windows 2000 dan Windows XP dapat sinkron atau asinkron. Perilaku default untuk I/O sinkron: fungsi I/O disebut dan kembali ketika I/O selesai. Asynchronous I/O, di sisi lain, memungkinkan fungsi I/O untuk eksekusi kembali ke pemanggil segera kembali, tapi I/O tidak dianggap lengkap hingga beberapa waktu masa depan. Sistem operasi akan memberitahu pemanggil ketika I/O selesai. Atau, pemanggil dapat menentukan status operasi I/O luar biasa dengan menggunakan layanan dari sistem operasi.

Keuntungan dari asynchronous I/O adalah bahwa pemanggil memiliki waktu untuk melakukan lain bekerja atau mengeluarkan lebih banyak permintaan sementara operasi I/O yang selesai. The istilah Overlapped I/O sering digunakan untuk Asynchronous I/O dan tumpang tindih Non I/O untuk I/O sinkron. Artikel ini menggunakan istilah Asynchronous dan Sinkron untuk operasi I/O di bawah Windows NT. Artikel ini mengasumsikan pembaca memiliki tertentu keakraban dengan File i/O fungsi seperti CreateFile, ReadFile, WriteFile.

Sering, operasi I/O asynchronous berperilaku seperti sinkron I/O. tertentu kondisi yang artikel ini membahas di bagian kemudian membuat I/O operasi lengkap serempak. Pemanggil tidak memiliki waktu untuk latar belakang bekerja karena fungsi I/O tidak kembali sampai I/O selesai.

Beberapa fungsi yang terkait dengan synchronous asynchronous I/O. Artikel ini menggunakan ReadFile dan WriteFile sebagai contoh; alternatif yang baik akan ReadFileEx dan WriteFileEx. Meskipun artikel ini membahas hanya disk i/O khusus, banyak dari prinsip-prinsip dapat diterapkan untuk jenis I/O, seperti serial I/O atau jaringan I/O.

CATATAN: Karena Windows 95 tidak mendukung asynchronous I/O pada disk perangkat (meskipun tidak pada jenis I/O device), perilaku yang tidak tercakup dalam artikel ini.

Mengatur Asynchronous I/O

Bendera FILE_FLAG_OVERLAPPED harus ditentukan dalam CreateFile ketika berkas dibuka. Bendera ini memungkinkan I/O operasi pada file harus dilakukan asynchronously. Berikut adalah contoh:Berhati-hati ketika coding untuk asynchronous I/O karena sistem cadangan hak untuk membuat suatu operasi sinkron jika perlu. Oleh karena itu, lebih baik jika Anda menulis program untuk menangani sebuah operasi I/O yang dapat diselesaikan baik serentak atau asynchronously. Kode sampel menunjukkan pertimbangan ini.

Ada banyak hal yang program dapat sementara menunggu asynchronous operasi untuk menyelesaikan, seperti antrian operasi tambahan, atau melakukan latar belakang pekerjaan. Sebagai contoh, kode berikut benar menangani tumpang tindih dan non-tumpang tindih selesai membaca operasi. Itu tidak apa-apa lebih dari menunggu I/O luar biasa untuk menyelesaikan:Perhatikan bahwa & NumberOfBytesRead yang dilewatkan ke dalam ReadFile berbeda dari & NumberOfBytesTransferred dilewatkan ke dalam GetOverlappedResult. Suatu operasi telah dibuat asynchronous, maka GetOverlappedResult digunakan untuk menentukan sebenarnya jumlah byte yang ditransfer dalam operasi setelah itu telah selesai. & NumberOfBytesRead dilewatkan ke dalam ReadFile bermakna.

Jika, di sisi lain, operasi selesai segera, kemudian & NumberOfBytesRead dilewatkan ke dalam ReadFile berlaku untuk jumlah byte yang membaca. Dalam kasus ini, mengabaikan struktur OVERLAPPED yang dilewatkan ke dalam ReadFile; tidak menggunakannya dengan GetOverlappedResult atau WaitForSingleObject.

Peringatan lain dengan operasi asynchronous adalah bahwa Anda tidak boleh menggunakan struktur OVERLAPPED sampai operasi tertunda telah selesai. Di lain kata-kata, jika Anda memiliki tiga operasi I/O luar biasa, Anda harus menggunakan tiga OVERLAPPED struktur. Jika Anda menggunakan kembali struktur OVERLAPPED, Anda akan menerima hasil yang tak terduga dalam operasi I/O dan Anda akan mengalami kerusakan data. Selain itu, sebelum Anda dapat menggunakan struktur OVERLAPPED untuk pertama kalinya, atau sebelum Anda kembali setelah operasi sebelumnya telah selesai, Anda harus benar menginisialisasi itu sehingga tidak ada data waktu-over mempengaruhi operasi baru.

Jenis-jenis pembatasan yang sama berlaku untuk penyangga data yang digunakan dalam operasi. Data buffer harus tidak dibaca atau ditulis sampai dengan operasi I/O terkait telah selesai; membaca atau menulis buffer dapat menyebabkan kesalahan dan data rusak.

Asynchronous I/O masih tampaknya sinkron

Jika Anda mengikuti petunjuk sebelumnya dalam artikel ini, namun, semua operasi I/O Anda masih biasanya menyelesaikan serempak dalam urutan yang dikeluarkan, dan tidak ada operasi ReadFile kembali palsu dengan GetLastError() kembali ERROR_IO_PENDING, ini berarti Anda tidak punya waktu untuk pekerjaan latar belakang. Mengapa hal ini terjadi?

Ada beberapa alasan mengapa I/O operasi lengkap serentak bahkan jika Anda telah dikodekan untuk operasi asynchronous:

Kompresi

Salah satu hambatan untuk operasi asynchronous adalah kompresi NTFS. File driver sistem tidak akan mengakses file terkompresi asynchronously; Sebaliknya semua operasi hanya membuat sinkron. Ini tidak berlaku untuk file yang dikompresi dengan utilitas serupa untuk KOMPRES atau PKZIP.

NTFS enkripsi

Mirip dengan kompresi, enkripsi berkas menyebabkan pengandar sistem untuk mengkonversi asynchronous I/O untuk sinkron. Jika file didekripsi, permintaan I/O akan asynchronous.

Memperluas File

Alasan lain bahwa operasi I/O selesai serentak adalah operasi sendiri. Pada Windows NT, setiap menulis operasi ke file yang memanjang panjang akan sinkron.

CATATAN: Aplikasi dapat membuat Operasi tulis disebutkan sebelumnya tak sinkron dengan mengubah panjang Data yang Valid file dengan menggunakan fungsi SetFileValidData, dan kemudian mengeluarkan WriteFile.

Menggunakan SetFileValidData (yang tersedia pada Windows XP dan versi yang lebih baru), aplikasi dapat secara efisien memperpanjang file tanpa menimbulkan hukuman kinerja untuk nol-mengisi mereka.

Karena sistem berkas NTFS tidak nol mengisi data hingga panjang data yang valid (VDL) yang ditentukan oleh SetFileValidData, fungsi ini memiliki implikasi di mana file dapat ditetapkan cluster yang sebelumnya ditempati oleh file lainnya. Oleh karena itu, SetFileValidData mengharuskan pemanggil memiliki SeManageVolumePrivilege baru diaktifkan (secara default, ini diberikan hanya kepada administrator). Microsoft menganjurkan bahwa ISVs hati-hati mempertimbangkan implikasi dari menggunakan fungsi ini.

Tembolok

Kebanyakan i/O driver (disk, komunikasi, dan lain-lain) memiliki kode kasus khusus di mana, jika permintaan I/O dapat diselesaikan "segera", operasi akan selesai dan akan mengembalikan fungsi ReadFile atau WriteFile benar. Dalam segala hal, jenis operasi tampak sinkron. Untuk disk perangkat, biasanya, permintaan I/O dapat diselesaikan "segera" ketika data cache di memori.

Data yang tidak dalam Cache

Skema cache dapat bekerja melawan Anda, namun, jika data tidak di cache. Windows NT cache dilaksanakan secara internal menggunakan file pemetaan. Manajer memori dalam Windows NT tidak menyediakan halaman asynchronous kesalahan mekanisme untuk mengelola pemetaan file yang digunakan oleh manajer cache. The cache manajer dapat, namun, memverifikasi apakah halaman yang diminta dalam memori, jadi jika Anda mengeluarkan yang asynchronous dibaca cache, dan halaman tidak dalam memori, driver sistem file menganggap bahwa Anda tidak ingin thread Anda diblokir dan permintaan akan ditangani oleh kolam terbatas pekerja benang. Kontrol kembali ke program Anda setelah Anda ReadFile panggilan dengan membaca masih tertunda.

Ini bekerja baik untuk sejumlah kecil permintaan, tetapi karena kolam pekerja benang terbatas (saat ini tiga pada sistem 16 MB), ada akan masih hanya beberapa permintaan antri untuk pengandar disk pada waktu tertentu. Jika Anda mengeluarkan banyak operasi I/O untuk data yang tidak dalam cache, cache manager dan manajer memori menjadi jenuh dan permintaan Anda dibuat sinkron.

Perilaku cache manajer dapat juga dipengaruhi berdasarkan Apakah Anda mengakses file secara berurutan atau secara acak. Manfaat dari cache dilihat sebagian besar ketika mengakses file secara berurutan. Bendera FILE_FLAG_SEQUENTIAL_SCAN dalam CreateFile panggilan akan mengoptimalkan cache untuk jenis akses ini. Namun, jika Anda mengakses file dalam mode acak, menggunakan Bendera FILE_FLAG_RANDOM_ACCESS di CreateFile untuk menginstruksikan manager cache untuk mengoptimalkan perilaku untuk akses acak.

Tidak menggunakan Cache

Bendera FILE_FLAG_NO_BUFFERING memiliki paling efek pada perilaku sistem berkas bagi operasi asynchronous. Ini adalah cara terbaik untuk menjamin permintaan I/O benar-benar asynchronous. Memerintahkan sistem berkas untuk tidak menggunakan apapun cache mekanisme sama sekali.

PERINGATAN: Ada beberapa pembatasan untuk menggunakan bendera ini yang harus dilakukan dengan data buffer keselarasan dan perangkat sektor ukuran. Melihat referensi fungsi dalam dokumentasi untuk fungsi CreateFile untuk informasi lebih lanjut tentang menggunakan bendera ini dengan benar.

CONTOH KODE

Berkas berikut ini tersedia untuk diunduh dari Pusat Unduhan Microsoft:
Untuk informasi lebih lanjut tentang cara men-download berkas Dukungan Microsoft, klik nomor artikel di bawah ini untuk melihat artikel pada Basis Pengetahuan Microsoft:Microsoft telah memindai berkas ini dari virus. Microsoft menggunakan perangkat lunak pendeteksi virus terbaru yang tersedia pada tanggal saat berkas dikirimkan. Berkas tersebut disimpan di server yang aman, yang membantu mencegah pengubahan yang tidak sah terhadap berkas.Kode contoh yang terkait dengan artikel ini menunjukkan penggunaan bendera dan fungsi yang dibahas. Kode berjalan sebagai aplikasi konsol pada Windows NT. Switch baris perintah berikut mengontrol perilaku:Operasi default dari program ini adalah untuk operasi asynchronous, buffered. Secara default, 500 operasi I/O diminta.

Hasil tes dunia nyata

Berikut adalah beberapa hasil tes dari kode contoh. Besarnya angka ini tidak penting di sini dan bervariasi dari komputer ke komputer, tetapi hubungan nomor dibandingkan dengan satu sama lain menerangi mempengaruhi umum dari bendera-bendera pada kinerja.

Anda dapat mengharapkan untuk melihat hasil yang mirip dengan berikut:

• Tes 1

  Asynchronous, unbuffered I/O:  asynchio /f*.dat /n
  
     Operations completed out of the order in which they were requested.
     500 requests queued in 0.224264 seconds.
     500 requests completed in 4.982481 seconds.
  						

  Tes ini menunjukkan bahwa program disebutkan sebelumnya mengeluarkan permintaan I/O 500 cepat dan memiliki banyak waktu untuk melakukan pekerjaan lain atau mengeluarkan lebih banyak permintaan.
• Test 2

  Synchronous, unbuffered I/O: asynchio /f*.dat /s /n
  
     Operations completed in the order issued.
     500 requests queued and completed in 4.495806 seconds.
  						

  Tes ini menunjukkan bahwa program ini menghabiskan 4.495880 detik Calling ReadFile untuk menyelesaikan operasi, sedangkan tes 1 menghabiskan hanya 0.224264 detik untuk mengeluarkan permintaan yang sama. Dalam tes 2, tidak ada waktu "tambahan" untuk program untuk melakukan latar belakang bekerja.
• Tes 3

  Asynchronous, buffered I/O: asynchio /f*.dat
  
     Operations completed in the order issued.
     500 requests issued and completed in 0.251670 seconds.
  						

  Tes ini menunjukkan sifat sinkron cache. Semua kali dibaca dikeluarkan dan selesai dalam 0.251670 detik. Dengan kata lain, permintaan asynchronous selesai serempak. Tes ini juga menunjukkan kinerja tinggi manajer cache ketika data dalam cache.
• Tes 4

  Synchronous, buffered I/O: asynchio /f*.dat /s
  
     Operations completed in the order issued.
     500 requests and completed in 0.217011 seconds.
  						

  Tes ini menunjukkan hasil yang sama seperti dalam tes 3. Perhatikan bahwa sinkron dibaca dari cache menyelesaikan sedikit lebih cepat daripada asynchronous dibaca dari cache. Tes ini juga menunjukkan kinerja tinggi manajer cache ketika data dalam cache.

KESIMPULAN

Anda dapat memutuskan metode mana yang terbaik karena itu semua tergantung pada jenis, ukuran dan jumlah operasi yang program Anda.

Akses file default tanpa menentukan bendera setiap khusus untuk CreateFile adalah operasi yang sinkron dan cache.

CATATAN: Anda mendapatkan beberapa perilaku asynchronous otomatis dalam mode ini karena driver sistem file tidak prediksi asynchronous dibaca-depan dan asynchronous malas menulis diubah data. Meskipun hal ini tidak membuat aplikasi [ASCII 146] s I/O asynchronous, itu adalah kasus yang ideal untuk sebagian besar aplikasi sederhana.

Jika, di sisi lain, aplikasi Anda tidak sederhana, Anda mungkin harus melakukan beberapa profil dan pemantauan kinerja untuk menentukan metode yang terbaik, mirip dengan tes yang digambarkan sebelumnya dalam artikel ini. Profil waktu dihabiskan di ReadFile atau WriteFile fungsi dan kemudian membandingkan kali ini ke cara lama dibutuhkan operasi I/O sebenarnya untuk menyelesaikan ini sangat berguna. Jika sebagian besar waktu yang dihabiskan dalam benar-benar mengeluarkan I/O, maka I/O Anda sedang selesai serempak. Namun, jika waktu mengeluarkan permintaan I/O adalah relatif kecil dibandingkan dengan waktu itu mengambil untuk operasi I/O lengkap, maka operasi Anda sedang dirawat asynchronously. Sampel kode yang disebutkan sebelumnya dalam artikel ini menggunakan fungsi QueryPerformanceCounter untuk melakukan sendiri Profil internal.

Pemantauan kinerja dapat membantu menentukan seberapa efisien program Anda menggunakan disk dan cache. Pelacakan salah satu performance counters for objek Cache akan menunjukkan kinerja cache manajer. Pelacakan penghitung kinerja Disk fisik atau Disk logis objek akan menunjukkan kinerja sistem disk.

Ada beberapa utilitas yang membantu dalam pemantauan kinerja; PerfMon dan DiskPerf yang terutama berguna. Untuk sistem untuk mengumpulkan data pada kinerja sistem disk, Anda harus mengeluarkan perintah -y diskperf. Setelah Anda mengeluarkan perintah, Anda harus me-restart sistem untuk memulai pengumpulan data.

Untuk informasi lebih lanjut tentang ini utilitas dan kinerja pemantauan, lihat volume "mengoptimalkan Windows NT" dalam Windows NT Resource Dokumentasi kit.

SQL Server memerlukan sistem untuk mendukung 'pengiriman dijamin stabil media' seperti diuraikan di bawah program Microsoft SQL Server Always-On penyimpanan solusi Review. FoUntuk informasi lebih lanjut tentang persyaratan input dan output untuk mesin database SQL Server, klik nomor artikel di bawah ini untuk melihat artikel di dalam Basis Pengetahuan Microsoft: