VS 2008 / net framework 3.0 3.5 / wpf - Dispatcher-Methods not thread safe

[Rolf Welskes]

Hello,
because there are no manged news groups for windows presentation foundation,
I was told to
send my question here.

Problem:
In the documentation of the class Dispatcher you can read:
Threading:
Any public static (Shared in Visual Basic) members of this type are thread
safe. Any instance members are not guaranteed to be thread safe.

This is the standard sentence you see very often.

Now:
This would mean:
If I had 3 worker threads and would like to update the gui I have to use in
the 3 worker thread
marshaling.
this means in the worker threads I would call for exampel
myWindow.Dispatcher.Invoke(......).
Ok this works.
BUT: If I take the senctence above, Invoke would not be thread-safe. Means
I had to synchronise each call of Dispatcher.Invoke.

I cannot believ this, because Dispatcher.Invoke and Dispatcher.BeginInvoke
are
for the purpose of marshaling from different threads.

So, question:
Is it right, do I have to synchronize the calls Dispatcher.Invoke,
Dispatcher.BeginInvoke or not ???

Thank you for any help.

Best Regards
Rolf Welskes

 

[Chris Jobson]

I cannot believ this, because Dispatcher.Invoke and

Surely your intuition is correct, and Dispatcher.Invoke() is thread-safe.

Control.Invoke(), the Forms namespace equivalent, is specifically called
out as being one of a handful of thread-safe methods for the Control
class. While the docs aren't as explicit about the Dispatcher.Invoke()
method, it stands to reason that it, BeginInvoke() and at least some other
Dispatcher methods are in fact thread-safe also. The fact that the
methods are specifically designed to be used in a multi-threaded way and
the sample code shows no synchronization code would I think bear this out.

Granted, I haven't looked at the implementation to double-check. But I
suspect that if you do (via Reflector or the Microsoft code download),
you'll find the necessary synchronization internally to ensure correct
operation (either explicit, or implicit via whatever underlying unmanaged
Win32 API is used).

The documentation for Dispatcher does say "All of the methods on Dispatcher,
with the exception of DisableProcessing, are free-threaded", which agrees
with your intuition.

Chris Jobson

 

[Chris Jobson]

I cannot believ this, because Dispatcher.Invoke and

Surely your intuition is correct, and Dispatcher.Invoke() is thread-safe.

Control.Invoke(), the Forms namespace equivalent, is specifically called
out as being one of a handful of thread-safe methods for the Control
class. While the docs aren't as explicit about the Dispatcher.Invoke()
method, it stands to reason that it, BeginInvoke() and at least some other
Dispatcher methods are in fact thread-safe also. The fact that the
methods are specifically designed to be used in a multi-threaded way and
the sample code shows no synchronization code would I think bear this out.

Granted, I haven't looked at the implementation to double-check. But I
suspect that if you do (via Reflector or the Microsoft code download),
you'll find the necessary synchronization internally to ensure correct
operation (either explicit, or implicit via whatever underlying unmanaged
Win32 API is used).

The documentation for Dispatcher does say "All of the methods on Dispatcher,
with the exception of DisableProcessing, are free-threaded", which agrees
with your intuition.

Chris Jobson

 

[Chris Jobson]

I cannot believ this, because Dispatcher.Invoke and

Surely your intuition is correct, and Dispatcher.Invoke() is thread-safe.

Control.Invoke(), the Forms namespace equivalent, is specifically called
out as being one of a handful of thread-safe methods for the Control
class. While the docs aren't as explicit about the Dispatcher.Invoke()
method, it stands to reason that it, BeginInvoke() and at least some other
Dispatcher methods are in fact thread-safe also. The fact that the
methods are specifically designed to be used in a multi-threaded way and
the sample code shows no synchronization code would I think bear this out.

Granted, I haven't looked at the implementation to double-check. But I
suspect that if you do (via Reflector or the Microsoft code download),
you'll find the necessary synchronization internally to ensure correct
operation (either explicit, or implicit via whatever underlying unmanaged
Win32 API is used).

The documentation for Dispatcher does say "All of the methods on Dispatcher,
with the exception of DisableProcessing, are free-threaded", which agrees
with your intuition.

Chris Jobson

 

[Chris Jobson]

The documentation for Dispatcher does say "All of the methods on

I wasn't actually able to find a definition of "free-threaded", but IMHO
it shouldn't be construed as being synonymous with "thread-safe".

I agree it's hard to find a definitive definition (I've probably got one in
a book somewhere, but having recently moved most of my books are in boxes in
the garage), but the following (COM-related) links give some help:
http://msdn.microsoft.com/en-us/library/ms693779(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms693421(VS.85).aspx

If they meant "thread-safe" I think they would have said so.

It would certainly have been easier if they had, but I can understand
someone coming from a COM background using the COM term by mistake. And it's
hard to see why they added the line I quoted at all if it didn't mean
something other than the default "instance methods are not thread-safe".

"Free-threaded" _seems_ to be more associated with COM threading models, Definitely.

and in that context all that it means is that COM isn't doing anything to
handle threading issues. Agreed.

In fact, in that context, "free-threaded" is a warning flag that your own
code needs to handle synchronization, which is the exact opposite of
"thread-safe".

No - it only means that if you're _writing_ the free-threaded code, not if
you're calling it. The object _implementing_ a free-threaded method must
expect that method to be called simultaneously from different threads and
must handle the synchronisation itself.

Regards
Chris