代碼運(yùn)行在UI線程中，當(dāng)執(zhí)行到dlg.ShowDialog時，啟動模態(tài)對話框，等待用戶點(diǎn)擊Yes/No或者關(guān)閉對話框，對話框關(guān)閉后程序繼續(xù)執(zhí)行SomeCodeB代碼。那么程序要在SomeCodeB處等待ShowDialog返回后才繼續(xù)執(zhí)行。當(dāng)然你可以使用WaitHandle來同步，不過這個需要掛起當(dāng)前（UI）線程，如果主窗口中有動畫等UI動作，那么會停止得不到響應(yīng)。這里WPF使用的是PushFrame，就是在ShowDialog內(nèi)部又建立起了一個消息泵。While（GetMessage（…））。一方面，可以確保UI線程中的消息可以被處理；另一方面，因?yàn)槭荳hile循環(huán)，在對話框關(guān)閉時返回，可以確保SomeCodeB的執(zhí)行順序。

那么是不是這個嵌套的消息循環(huán)真的如此完美呢？當(dāng)然不是，它打開了一扇門的同時，也打開了另一扇門。一個情景，當(dāng)收到WM_SIZE消息的時候，Layout系統(tǒng)開始處理，如果在這個處理過程中，又啟動了PushFrame，那么嵌套的消息泵就會繼續(xù)從消息隊列中取出消息，如果下一個消息也是WM_SIZE，那么進(jìn)行處理。假設(shè)這個消息處理結(jié)束后這個嵌套的消息泵返回了，那么第一個WM_SIZE得以繼續(xù)處理。這樣就發(fā)生了錯誤，本來12的處理順序變成了121。當(dāng)然這種情況不僅僅發(fā)生在Layout中，所以WPF在Dispatcher中加入了一個DisableProcessing函數(shù)，在Layout等關(guān)鍵過程中調(diào)用了這個函數(shù)，在這個過程中停止pump消息和禁止PushFrame。

在WPF中，所有的WPF對象都派生自DispatcherObject，DispatcherObject暴露了Dispatcher屬性用來取得創(chuàng)建對象線程對應(yīng)的Dispatcher。鑒于線程親緣性，DispatcherObject對象只能被創(chuàng)建它的線程所訪問，其他線程修改DispatcherObject需要取得對應(yīng)的Dispatcher，調(diào)用Invoke或者BeginInvoke來投入任務(wù)。一個UI線程至少有一個Dispatcher來建立消息泵處理任務(wù)，一個Dispatcher只能對應(yīng)一個UI線程。那么UI線程和Render線程又如何呢？

開篇提到，WPF線程一分為二，一個是UI線程，一個是Render線程。這兩個被設(shè)計成分離的關(guān)系，通過Channel（event）來進(jìn)行通信。兩者之間的數(shù)量關(guān)系是一個WPF進(jìn)程只能有一個Render線程，旦可以有大于等于一個的UI線程。通常情況下是一個UI線程，也就是一個Dispatcher，那么什么情況下需要建立多個呢？

大多情況下是不需要的，少數(shù)情況下，比如MediaElement，或者Host其他ActiveX控件，我們期望在其他線程中創(chuàng)建，以提高性能?？梢孕陆ň€程，在新線程中創(chuàng)建控件，并調(diào)用Dispatcher.Run啟動Dispatcher。這樣主Window和新控件就處在不同線程中，兩者間的通信可以使用VisualTarget連接視覺樹或者使用D3DImage拷貝新控件到主Window中顯示。