In WPF4 Unleashed Adam Nathan states:
Most WPF classes derive from DispatcherObject and are therefore
inherently thread-unsafe.
Professional WPF Programming claims the opposite:
DispatcherObject is the lowest level class in the framework hierarchy,
and because almost all objects inherit from it, most objects are
inherently thread-safe
MSDN on DispatcherObject:
Only the thread that the Dispatcher was created on may access the
DispatcherObject directly. To access a DispatcherObject from a thread
other than the thread the DispatcherObject was created on, call Invoke
or BeginInvoke on the Dispatcher the DispatcherObject is associated
with.
Based on MSDN description it looks like WPF4 Unleashed quote was either a typo or Nathan was just wrong and the Professional WPF Programming authors were right…
Anyway, are classes inheriting from DispatcherObject inherently thread-safe or inherently thread-unsafe?
EDIT:
MSDN also states:
Subclasses of DispatcherObject that need to enforce thread safety can
do so by calling VerifyAccess on all public methods. This guarantees
the calling thread is the thread that the DispatcherObject was created
on.
This indirectly confirms that WPF4 Unleashed claim was accurate after all…
It depends what you mean by thread-safe, but I’d favour the view of WPF4 Unleashed – based on the MSDN description.
The documentation says that you can only access members of the
DispatcherObjecton a particular thread – so it’s unsafe to use it from arbitrary threads. That sounds like it’s a thread-unsafe type to me.On the other hand, you could consider that if a
DispatcherObjectis used correctly, the code within the class doesn’t have to take thread safety into account, as it should only be invoked from a single thread.So in some sense it’s “thread-unsafe from the outside, thread-safe from the inside”. I would prefer to use a term which is more descriptive: the classes have thread affinity.