wpf 4.5已經改進了其對於多執行緒資料繫結的支援，但所用技術卻帶有風險。本文將會介紹其工作原理以及如何才能確保安全使用。
wpf資料繫結對於多執行緒的支援一直都沒什麼具體計畫。當物件在非ui執行緒上發出了屬性變化事件時，資料繫結基礎設施就會對其作出響應。通常這是可行的，但因為潛在的競態條件，這麼做並不是真正安全的。從電腦科學的視角來看，禁用跨執行緒的訪問是更為正確的做法，因為這才是導致集合變化事件的根源。
但遺憾的是，開發者並不總是在意正確性，他們只是想把事情做完。這樣，他們會使用各種「執行緒安全」或是「分發安全」的可觀測集合。在所有這些做法中，基本的設計就是在呼叫前將集合變化的事件編排到正確的執行緒中。在這種情況下，正確的執行緒就是分發者所執行的那個執行緒。但遺憾的是，這麼做並未消除競態條件的可能性。
在wpf 4.5中，微軟向開發者提供了一種更為安全的解決方案。通過呼叫bindingoperations.enablecollectionsynchronization，wpf資料繫結引擎會使用鎖。其預設行為是獲得前述呼叫所指定物件上的鎖，但你也可以使用更為複雜的鎖模式。但遺憾的是，這種方式很容易出錯；對於後台執行緒來說，你很容易忘記獲得集合的鎖。當集合不再需要時，你還可能忘記禁用集合同步，這會導致記憶體洩露。
該技術的另乙個問題是它並不會保護單個物件。這樣當在鎖下讀取集合時，集合中每一項的屬性就不一定能夠保證會被安全讀取。這對於複雜的getters以及無法以原子方式進行設定的屬性來說極易產生問題（比如說大的值型別）。
我們強烈建議使用後台執行緒的開發者只使用集合中的不變物件來更新集合。如果物件無法保證是不變的，那麼至少在確保屬性getters的執行緒安全上要格外小心。當向集合中新增物件時，你最好不要使用該特性，而是將集合更新編排到ui執行緒中。
檢視英文原文：multithreading and wpf 4.5
WPF 4 5對於多執行緒下的繫結支援
wpf資料繫結對於多執行緒的支援一直都沒什麼具體計畫。當物件在非ui執行緒上發出了屬性變化事件時，資料繫結基礎設施就會對其作出響應。通常這是可行的，但因為潛在的競態條件，這麼做並不是真正安全的。從電腦科學的視角來看，禁用跨執行緒的訪問是更為正確的做法，因為這才是導致集合變化事件的根源。但遺憾的是，開...
WPF 4 5中對繫結的改善
儘管wpf已經不再是明星產品，但它在windows富客戶端開發中的地位還是舉足輕重。它擁有對.net類庫以及底層作業系統完全的訪問許可權，沒 有任何其他html或者基於.net的使用者介面技術能夠與之相提並論。微軟意識到了它的重要性，並將繼續對其投資以做出改善，特別是對其繫結 binding 功能。...
WPF多執行緒
需求 wpf在主線程運算元據庫等一些聯網操作時，會影響介面造成卡頓，gui卡頓 解決方案 引入多執行緒解決來解決gui卡頓問題。新建執行緒 方法一 在新建執行緒中呼叫已有函式 thread thread new thread connmysql connmysql是子函式，在此執行緒呼叫子函式 th...