Saya telah bekerja melalui artikel tentang metode pengontrol asinkron dalam ASP.NET MVC ( http://visualstudiomagazine.com/articles/2013/07/23/async-actions-in-aspnet-mvc-4.aspx ) dan saya pikir Saya mungkin kehilangan intinya.
Pertimbangkan metode ini yang saya tulis, yang sangat mirip dengan contoh dari artikel:
[HttpGet]
[AsyncTimeout(8000)]
[HandleError(ExceptionType = typeof(TimeoutException), View = "TimedOut")]
public async Task<ActionResult> Index(CancellationToken cancellationToken)
{
WidgetPageViewModel model = new WidgetPageViewModel()
{
toAdd = new Widget()
};
model.all = await _repo.GetAllAsync(cancellationToken);
return View(model);
}
Seperti yang saya pahami, inilah yang akan terjadi saat runtime:
Utas ASP.NET akan dibuat untuk permintaan HTTP yang masuk.
Utas ini akan (setelah melakukan beberapa pekerjaan awal yang diperlukan) memasukkan metode Indeks saya () di atas.
Eksekusi akan mencapai kata kunci "menunggu" dan memulai proses akuisisi data pada utas lainnya.
Utas "ASP.NET" yang asli akan kembali ke kode yang disebut metode penangan saya, dengan turunan tugas kelas sebagai nilai kembali.
Kode infrastruktur yang disebut metode penangan saya akan terus beroperasi pada utas "ASP.NET" yang asli, hingga mencapai titik di mana ia perlu menggunakan objek ActionResult yang sebenarnya (misalnya untuk merender halaman).
Penelepon kemudian akan mengakses objek ini menggunakan anggota Task.Result, yang akan menyebabkannya (yaitu utas "ASP.NET") untuk menunggu utas yang dibuat secara implisit pada langkah # 3 di atas.
Saya tidak melihat apa yang dicapai ini dibandingkan dengan hal yang sama tanpa menunggu / async, kecuali untuk dua hal yang saya anggap remeh:
Utas penelepon dan utas pekerja yang dibuat oleh menunggu dapat beroperasi secara paralel untuk beberapa periode waktu (bagian "hingga" dari # 5 di atas). Firasat saya adalah bahwa periode waktu cukup kecil. Ketika infrastruktur memanggil menjadi metode pengontrol, saya pikir umumnya membutuhkan ActionResult panggilan pengontrol yang sebenarnya sebelum dapat melakukan banyak (jika ada) lebih banyak.
Ada beberapa infrastruktur baru yang bermanfaat terkait dengan batas waktu dan pembatalan operasi pengontrol asinkron yang sudah berjalan lama.
Tujuan menambahkan metode pengontrol async seharusnya membebaskan thread pekerja ASP.NET tersebut untuk benar-benar menjawab permintaan HTTP. Utas ini adalah sumber daya yang terbatas. Sayangnya, saya tidak melihat bagaimana pola yang disarankan dalam artikel sebenarnya berfungsi untuk melestarikan utas ini. Dan bahkan jika itu terjadi, dan entah bagaimana membebani beban penanganan permintaan ke beberapa utas non-ASP.NET, apa yang dicapai? Apakah utas yang kebetulan mampu menangani permintaan HTTP yang jauh berbeda dari utas pada umumnya?
Execution will reach the "await" keyword and kick off a data acquisition process on another thread
-- Belum tentu.async
tidak memerlukan utas lainnya ... Ini merupakan kelanjutan. Itu dapat dilakukan dengan menyusun ulang instruksi pada utas yang sama.