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

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

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

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

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