A Creditex Swing developer explained to me that UI redraw is an operation happening on the dispatcher thread. This thread should be the only thread that modifies UI objects, otherwise the screen may get messed up by uncoordinated concurrent updates.
Suppose you have an onMsg() listener triggered by market data. This onMsg() obviously runs in it’s own thread, which blocks until waken up by incoming message. If a naive developer decides to modify some JTable object in onMsg() thread, and at the same time another timer thread is also updating the JTable, and the event-dispatcher thread is redrawing the screen … display will change in unexpected ways.
In WPF, every UI control is owned by the UI thread ie the dispatcher thread, according to Longbo — Good simplification. No other thread can modify UI controls, though they can modify the data binding (models?) behind the UI controls. To effect a change on UI, other threads must go through dispatcher thread as the choke point of control. I was told this is done by some event publication model, probably with INotifyPropertyChanged.
[[Learning java]] shows swing has a single event queue — see my post on async buffer. If UI thread is in the middle of some long calculation when you publish, then synchronous call is not possible. In fact, synchronous call would mean the event sender thread is the only thread involved, which is the scenario  above.