小結： 對於開發者來說幸運的是：線程在asp.net中遠遠比在asp中來的容易。本篇文章中，作者注視線程於asp.net http pipeline中，同時解釋線程在開發者沒有捲入的情況是如何被高效管理的。 本篇文章考慮CLR線程池是如何被asp.net 服務請求使用的，還有池在處理，模型，和應用的機制，覆蓋惡劣IIS5 和IIS6，及它們在請求處理和線程分配的不同。最後，探討了對於需要使用線程的開發者來說，何時和如何使用異步處理在他們的應用中。
在傳統的asp中，開發者面對線程問題之於他們知道應該要做什麼要多。因為asp是建立於com之上的，關於元件的線程需求這兒有非常詳細而精確的規範。頁面所使用的元件為了最大效率原因需要置於公寓線程中。相反地，在Session 和應用狀態中的元件需要便捷的環境並且能夠聚合於自由線程集合中，也能夠保護他們的狀態防止被並發的訪問。
如果你查看asp.net的文檔，結果你會發現關於線程需求是如此之少。難道這就意味著所有的線程問題都被解決了並且asp.net開發者可以放心的去開發他們的aspx頁面和NFC沒有混亂在並發問題上？ 不，大多數情況下並不是這樣。
本文中，我將在不增加開發者負擔的情況下，探索http 管道中線程的細節和如何有效的管理線程。同時我將看一下asp.net如何使用CLR 線程池處理服務請求的。
Asp.net中的線程
為了有效的服務多個客戶請求，Web Server 通過使用多個進程或生成多個線程來響應服務請求。Asp.net 沒使用異常和在一個進程中響應請求使用多個線程。基於這個現狀，asp.net開發者不需要關心多線程環境問題。頁面需求響應總是在一個線程中， 並且當有一個新的需求時，一個新的頁面將會創建一個截然不同的實例。應用的不同實例和模型元件總是被響應每一個請求。 然而，理解如何使用線程來響應請求是非常重要的。
開始之際，asp.net使用CLR線程池響應請求。池的大小在機器配置文件中（machine.config），默認被設置為25工作線程 和25個I/O線程：
<processModel enable="true"
•••
maxWorkerThreads="25"
maxIoThreads="25" />
（待續）
|
|
當前位置：開發者網絡 >> 技術教程 >> .NET教程 >> 算法/線程 >> 內容
