Messenger and multiple threads

Jun 8, 2010 at 8:05 PM


I've just checked the code of the messenger and I do think that the messenger is not thread safe.
When I have multiple threads where messages are send and objects register for receiving messages most of the collection iterations will fail because the collections are getting modified while iterating over them.
I have not used you framework yet, but the code seems to be prone to it.



Jun 8, 2010 at 8:51 PM


Actually the collections are cloned before the iteration occurs. They are not, however, locked.

That said, I recommend against send messages across threads. The recommended way is to leave the Messenger on the main thread, and to dispatch the call using the Dispatcher class. The problem is that the Messenger is often used to update properties of UI elements, and this cannot work across threads.

If you have a specific issue with multithreading and the messenger, I’d be happy to look into it.




Jun 9, 2010 at 7:41 AM
Edited Jun 9, 2010 at 7:42 AM

> The problem is that the Messenger is often used to update properties of UI elements, and this cannot work across threads.

This lib is intended to be used with MVVM. So it's all about binding against properties of the model. WPF has no problem when binding against properties that were modified on a different thread. The only exception is the observable collection but it can be easily replaced by a derived class, for example this one:

We're using a messenger in our project which is thread safe and we have lots of async calls without problems.



Jun 9, 2010 at 8:06 AM


What you are talking about is cross-thread access, not thread synchronization as I first thought. Ignore my previous answer.

The reason why the MVVM Light Messenger does not dispatch between threads is by design. I dislike hiding the dispatching within the Messenger object for two reasons:

1) Multithreading is very complex, and I feel that it is easier to find errors when the dispatching is done explicitly.

2) Dispatching within the Messenger would complicate the Messenger's API. It becomes necessary to pass parameters for the priority with which messages need to be dispatched, for instance. I decided not to add this complexity within the Messenger.

Instead, dispatching the message is the responsibility of the caller. I provide the DispatcherHelper class (which is a work in progress, granted, but covers most simple scenarios) to help the user with that.

It is not excluded that this changes in the future, and that the Messenger becomes more thread aware. I am careful however not to include too much complexity inside the Messenger for the reasons stated above.

I hope that it makes sense,



PS: Regarding asynchronous collections: I see some scenarios where they can be useful, but in general I recommend against them. Unit testing an asynchronous collection is very difficult. As a rule, I think that Observable collections (and arrays and dictionaries...) should belong to the UI thread and be modified on that thread only.