| Groups | Blog | Home |
dotnet framework : VS 2008 / net framework 3.0 3.5 / wpf - Dispatcher-Methods not thread safe
[quoted text, click to view] wrote: > [...] > 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 ??? 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).
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
[quoted text, click to view]
>> 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 ??? > > 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
[quoted text, click to view]
>> 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 ??? > > 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
[quoted text, click to view]
>> 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 ??? > > 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
On Sat, 31 May 2008 01:16:30 -0700, Chris Jobson
[quoted text, click to view] <chris.jobson@btinternet.com> wrote: > 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. 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". If they meant "thread-safe" I think they would have said so. "Free-threaded" _seems_ to be more associated with COM threading models, and in that context all that it means is that COM isn't doing anything to handle threading issues. 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". :)
[quoted text, click to view]
>> The documentation for Dispatcher does say "All of the methods on I agree it's hard to find a definitive definition (I've probably got one in >> Dispatcher, >> with the exception of DisableProcessing, are free-threaded", which agrees >> with your intuition. > > 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". 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 [quoted text, click to view] > 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". [quoted text, click to view] > "Free-threaded" _seems_ to be more associated with COM threading models, Definitely.[quoted text, click to view] > and in that context all that it means is that COM isn't doing anything to Agreed.> handle threading issues. [quoted text, click to view] > In fact, in that context, "free-threaded" is a warning flag that your own No - it only means that if you're _writing_ the free-threaded code, not if > code needs to handle synchronization, which is the exact opposite of > "thread-safe". :) 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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |