Re: Can I create a thread safe Winform User Control
- From: Ethan Strauss <EthanStrauss@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 23 Nov 2009 08:07:01 -0800
Thanks Pete,
That was quite helpful. I didn't even know thread affinity existed!
Ethan
"Peter Duniho" wrote:
Ethan Strauss wrote:.
[...]
A strange thing I just noticed is that, using vsto, the controls in the
ribbon (Microsoft.Office.Tools.Ribbon.RibbonControl) don't have an
InvokeRequired property. I wonder if they are already thread safe?
Careful. There's a difference between the thread affinity that involves
InvokeRequired and thread safety. For example, even if you synchronized
all access to your System.Windows.Forms.Control sub-classes so that an
instance was ever only accessed on one thread at a time, you would
_still_ have the requirement that the non-client class members (i.e.
those not added by you in a sub-class) be accessed only on the thread
that owns the instance.
Conversely, just because some other type of GUI control doesn't inherit
from the System.Windows.Forms.Control class, nor have an InvokeRequired
property, that doesn't mean that the type is thread-SAFE. It just
(probably) means that the control doesn't have the same thread affinity
issue that the System.Windows.Forms.Control sub-classes do.
(I say probably because the control you're asking about is part of the
Office interop types, which I'm not that familiar with. I don't know
for sure that it doesn't have a thread affinity issue).
I found
this statement "Any public static (Shared in Visual Basic) members of this
type are thread safe. Any instance members are not guaranteed to be thread
safe. " about ribbon controls, but I am not sure what is meant by "public
static members" and "instance members". That's from
http://msdn.microsoft.com/en-us/library/microsoft.office.tools.ribbon.ribboncontrol.aspx
That language is Microsoft's standard boilerplate language for .NET
types. Again, it doesn't relate to thread affinity, but rather to
thread safety, which is not quite the same thing.
In particular, in that type (and others with the same comment, which is
something like 90% or more of .NET) your code can safely access static
members of the type without synchronization between threads. But for a
given instance, your own code is required to handle synchronization if
more than one thread is accessing members _of that instance_ at the same
time.
Note that individual instances are independent of each other. You can
access instance members of one instance in one thread and instance
members of a different instance in another thread without needing to
synchronize the two threads.
Note also that for controls that _do_ have thread affinity, the thread
safety issue tends to be moot, because your code is always only ever
accessing instances of controls like that on the thread that owns the
control. The control is, in addition to having thread affinity, also
_not_ thread safe for instance members, but because you can't even
access the members of the class except on the owning thread, the lack of
thread safety isn't an issue (*).
Pete
(*) (unless, of course, you are dealing with your own sub-class and
members that you know to not have thread affinity issues...then you do
have to deal with the lack of thread-safety if you choose to access
those client-declared members in multiple threads simultaneously).
.
- References:
- Can I create a thread safe Winform User Control
- From: Ethan Strauss
- Re: Can I create a thread safe Winform User Control
- From: Peter Duniho
- Re: Can I create a thread safe Winform User Control
- From: Ethan Strauss
- Re: Can I create a thread safe Winform User Control
- From: Peter Duniho
- Can I create a thread safe Winform User Control
- Prev by Date: Re: Running a stored proc that will take a while.
- Next by Date: About a DataSet
- Previous by thread: Re: Can I create a thread safe Winform User Control
- Next by thread: SSh login
- Index(es):
Relevant Pages
|
