HttpContext的線程安全

經過一番Google搜索之後，我還沒有找到任何有關HttpContext線程安全性的權威信息。HttpContext的線程安全

我在看的場景，如：

public class AsyncHandler : IAsyncHttpHandler 
{ 
    void BeginProcessRequest(...) 
    { 
     // Spawn some tasks in parallel, provide them with current HttpContext as argument. 
    } 

    void EndProcessRequest(...) {...} 
}

我（IO綁定）並行任務將要訪問的HttpContext，可能在同一時間。

環顧各個職位似乎這是安全的，但是，我想要一些實際的證據。當然，MSDN給出了通常的「靜態線程安全等等」，但這並沒有幫助，除非我不得不假設它不是線程安全的。

我見過StackOverflow上的各種帖子（如here或here或here），但沒有真正的回答這個問題。

在.NET 4.5中的所有異步工作，如果HttpContext不是線程安全的，看起來有點奇怪，但是，如果事實並非如此，是否有任何方法來實現它？我可以想到：

克隆它（但這並不那麼容易，儘管看起來似乎不可能）。
包裝HttpContextBase並使此線程安全（嘿，我會叫它HttpContextWrapperWrapper）。

但這一切都感覺有點蹩腳和太多的工作。

編輯：在更詳細地研究了這個和稍後的一些反射之後，我相信它實際上並不重要，HttpContext不是線程安全的。我在this博客文章中詳細介紹了這一點。要點是在ASP.NET中使用正確的SynchronizationContext可以確保一次只有一個線程不會訪問上下文。

來源

2012-11-17 Marcus

我不認爲這是一個明確的削減情況 - 我想你需要詳細說明你想要執行什麼樣的修改 - 我當然不知道如果多線程會發生什麼情況試圖設置/重置相同的響應頭。 –

我一直在想的是閱讀，比如查詢參數，而不是像標題一樣設置。我同意我不知道我期望會發生什麼。在同一時間寫入響應流也是沒有意義的。 – Marcus

HttpContext類不是線程安全的。

例如，HttpContext.Items屬性只是對非同步Hashtable的引用 - 所以這顯然不是線程安全的。

從您的問題中不清楚您想要在並行任務之間共享什麼，但我建議您使用您自己的線程安全類的實例在任務之間共享狀態，而不是嘗試包裝現有類。

來源

2012-11-17 18:45:21 Joe

簡單但令人信服的答案，這確實似乎是要走的路。儘管Items是一個IDictionary（因此*可以是線程安全的），但它實際上似乎是由其IsSynchronized屬性返回false的HashTable實現的。 – Marcus

HttpContext的線程安全

回答

相關問題