Here it is plain and simple. The view sends an asynchronous message to the model. The model returns an asynchronous message to an interface. 

In Java, we have to work within the single threaded model of swing so this makes everything plain and simple. Why asynchronous? Well, in a complicated gui, the model is often required to perform time intensive task. This allows the gui thread to continue to update the gui, as the model makes calls to the server or whatever it needs to do before it returns a response. 

You should end up with two threads, the gui thread (the dispatch thread in swing) and the model thread which processes all the messages sent the models. Work queues are used to send messages back and forth. You may add more threads to process model messages, but then you have to worry about the order that tasks complete. If you still must multithread model work, then you can add some simple code to publish messages back to the gui in the order that the work was enqueued. 

Also, the use of interfaces makes swapping "views" for testing very easy. If you have designed well, then swapping in a synchronous interface for testing should be simple. Consider using DynamicProxies for the model to interface interaction. The sole responsibility of the proxy is to translate messages from one thread to another. In swing this means moving from any thread to the dispatch thread. During testing, you will want to use a dynamic proxy that will be synchronous or will send the event to the testing queue for processing. 

----

I used almost exactly that in my current project. I knew that we might be using something other than Swing later so I decoupled everything with LOTS of interfaces. Everything that is requested of the model goes into an interface and everything requested of the view goes into another interface. You end up with interfaces for related operations: editing this or that, selecting things on the one hand, displaying single or multiple things on the other. Then you have dynamic proxies, as mentioned, to decouple threading models. All that works out quite neatly and you can read the interfaces to see what the system does. But you do end up with an awful lot of classes to manage, esspecially in the creation of the implementing objects and their introduction to oneanother.  I didn't get all that right, it became very messy, trying to find which object had created what and connected it with whom.

----

Using only two threads seems to me to be a trap. Often you can end up with essentially a synchronous interface since any operation on the model that takes a long time locks the model so you can't do anything else while it is processed. Usually the best solution is to build everything to support asynchronous interfaces from the ground up (particularly for slow operations such as network, disk i/o, etc.) and then fit everything with callbacks. Usually you only need a message queue on the front-end view (provided and required by most GUI toolkits actually), but of course you have to be careful to write your code to protect everything without creating contention over locks. Generally the closer you can get to a functional style the better, as functional code doesn't reference shared memory which it has to lock on. It's a tricky way to write software, but becoming necessary for anything that's going to be useable. -bdodson
----
  http://upload.wikimedia.org/wikipedia/commons/thumb/b/bb/Matrix.svg/200px-Matrix.svg.png
  http: //en.wikipedia.org/wiki/File:Star_Trek_Warp_Field.png
  http://upload.wikimedia.org/wikipedia/commons/thumb/e/e6/Thin_filament_formation.svg/200px-Thin_filament_formation.svg.png
----
See also 
AsynchronousProgramming
ModelViewController
GuiThread
EventQueue
MetaModel