33

Well lets say i have an object that i databind to, it implements INotifyPropertyChanged to tell the GUI when a value has changed...

if i trigger this from a different thread than the GUI thread how would wpf behave?

and will it make sure that it gets the value of the property from memory and not the cpu cache?

more or less im asking if wpf does lock() on the object containing the property...

Peter
  • 37,042
  • 39
  • 142
  • 198

3 Answers3

50

Value changes fired by INotifyPropertyChanged are automatically marshalled back onto the dispatcher. (http://blog.lab49.com/archives/1166)

Fire this event on any thread you like...

Value changes fired by INotifyCollectionChanged are NOT reliably marshalled onto the dispatcher. (http://csharplive.wordpress.com/2008/09/11/wpf-data-binding-observablecollection-cross-thread-binding-support/)

If you need to update an observable collection from a different thread, follow the advice in this link

A. Levy
  • 29,056
  • 6
  • 39
  • 56
Rob Fonseca-Ensor
  • 15,510
  • 44
  • 57
  • +1 Ha! Learn a new thing everyday. Just did a quick test to confirm this....I am sure I had to marshall values to UI thread when working with wpf...maybe I am just going senile... – ozczecho Mar 31 '10 at 14:06
  • 1
    You certainly have to marshal any calls against an actual control (`textBox.Text="Foo")`, but the databinding framework helps a little. – Rob Fonseca-Ensor Mar 31 '10 at 14:08
  • What if i write a value to the private variable that the property uses and then fire the event, then the "GUI" thread goes about to read the value, but it has a old value cached on the CPU Cache... is there any handeling of this that makes sure that the value is not old or cached?... – Peter Mar 31 '10 at 16:30
  • @Petoj Even if .Net didn't handle that for you, Databinding happens computer-YEARS after all other threads have finished calculating things. You'll be fine... – Rob Fonseca-Ensor Mar 31 '10 at 17:05
  • That observable collection one has bitten me many many times. what a pain. – John Gardner Dec 10 '10 at 17:59
  • Try the following link which provides a thread-safe solution that works from any thread and can be bound to via multiple UI threads : http://www.codeproject.com/Articles/64936/Multithreaded-ObservableImmutableCollection – Anthony Apr 15 '14 at 19:23
  • 2
    Not so true for WPF4.5: https://msdn.microsoft.com/en-us/library/bb613588(v=vs.110).aspx#xthread_access – vines Apr 06 '15 at 00:48
  • 7
    csharplive.wordpress.com is down, what was the advice to follow ? – franssu Sep 25 '15 at 09:47
  • 1
    @franssu [web.archive.org](https://web.archive.org/web/20140606045433/http://csharplive.wordpress.com/2008/09/11/wpf-data-binding-observablecollection-cross-thread-binding-support/) [2](https://web.archive.org/web/20140228064043/http://codestand.feedbook.org:80/2008/09/wpf-data-binding-observablecollection.html) – Кое Кто Oct 25 '18 at 13:40
4

In addition to @Rob Fonseca-Ensor's answer, there is some good news for those lucky enough to use WPF4.5:

WPF enables you to access and modify data collections on threads other than the one that created the collection. This enables you to use a background thread to receive data from an external source, such as a database, and display the data on the UI thread. By using another thread to modify the collection, your user interface remains responsive to user interaction. (https://msdn.microsoft.com/en-us/library/bb613588(v=vs.110).aspx#xthread_access)

There's a helpful summary by Jonathan Antoine: http://www.jonathanantoine.com/2011/09/24/wpf-4-5-part-7-accessing-collections-on-non-ui-threads/

vines
  • 5,160
  • 1
  • 27
  • 49
-1

In practice it seems to work as expected and seems to be thread-safe (haven't seen anything odd happen or exceptions as a result of updating on background thread). I believe it invokes on to the UI thread when needed, but I'm not too familiar with the internals.

Davy8
  • 30,868
  • 25
  • 115
  • 173