Question

I recently read the Head First Design Patterns book and I especially liked how the chapter on MVC seemed to bring everything together from the previous chapters. However, I am now on the verge of implementing a MVC pattern (using wxWidgets in C++) and I am beginning to realize that I don’t understand threading issues as much as I should.

I have a View that must be updated continuously as the Model changes, however, a user can interact with the Control and also affect the Model. Since the View/Control and the Model will be running in 2 different threads (or is it 3?), how do I ensure that I don’t have two threads writing to the same data object? Am I responsible for setting up locks on the shared data? Or am I just somehow guaranteed to not have any problems as long as I use the events framework properly?

Answer 1

MVC was thought up originally for message based systems (Smalltalk), what in a sense is an opposite to multi-threading.

Best (theoretical) way known to me how to marry the MVC and multi-threading is the active object (or actor) concept: the object lives in its own threads, can send/receive messages/events to other active objects. That assumes that all actions on the object are synchronized – since single objects is bound to a single thread – what is analogue of a per-object mutex.

I have a View that must be updated continuously as the Model changes, however, a user can interact with the Control and also affect the Model. Since the View/Control and the Model will be running in 2 different threads (or is it 3?),

I have no experience with wxWidgets, but generally GUI part of an application is single-threaded (apparently valid for wxWidgets too), running exclusively in the main thread.

View and Controller are UI bound, thus have to run in the main thread. With extra thread for the Model that makes it 2.

how do I ensure that I don’t have two threads writing to the same data object?

Per-object mutex.

Am I responsible for setting up locks on the shared data?

Yes.

Or am I just somehow guaranteed to not have any problems as long as I use the events framework properly?

No. As mentioned above, GUI is single-threaded. If you start you own threads, then you have to take care of the synchronization.

If from the main/GUI thread you trigger an action in other thread, then obviously you need to synchronize the access to the shared data. If other thread wants to access GUI, then you have to use special functions (mentioned in the linked article) to trigger events in the main GUI thread (e.g. Model was updated in background threads, View has to redraw it in the main thread).

If background thread is updating continuously the Model, then obviously special care has to be taken that the thread doesn’t keep the mutex locked all the time so that the main thread, GUI, where View runs can access the model too. (Some sort of readers-writer lock is desirable.) Controller has to be disabled, since if application does something in the background, user interaction might be undesirable.

Overall, I think it is better to keep the MVC in the main thread. GUI thread doesn’t generate much of CPU load and oftentimes the idle events (wx has them too) are sufficient to simulate background job.