Is this really an Illegal Cross Thread Call?

Dave,

But I am locking before I touch the shared data, so do I actually need to
worry about this, or is it just the debugger being oversimplistic?

Yes the warning is right. You should only access Winforms controls
from the thread they were created on. Lock doesn't help here.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Hi,
Thank you for posting.
If you use multithreading to improve the performance your Windows Forms
applications, you must be careful to make calls to your controls in a
thread-safe way.

Access to Windows Forms controls is not inherently thread safe. If you have
two or more threads manipulating the state of a control, it is possible to
force the control into an inconsistent state. Other thread-related bugs are
possible as well, including race conditions and deadlocks. It is important
to ensure that access to your controls is done in a thread-safe way.

The .NET Framework helps you detect when you are accessing your controls in
a manner that is not thread safe. When you are running your application in
the debugger, and a thread other than the one which created a control
attempts to call that control, the debugger raises an
InvalidOperatio nException with the message, "Control control name accessed
from a thread other than the thread it was created on."

To make the access to your controls in a thread-safe way, you should use
the Invoke method of the control. The following is a sample.

delegate void WriteOutDelegat e(ref string Payload);
void test_Callback(r ef string Payload)
{
object[] args = new object[1]{Payload};
this.Invoke(new WriteOutDelegat e(WriteOut),arg s);
}

private void WriteOut(ref string Payload)
{
this.Text = Payload;
}

Hope this will help you.
If you have any other concerns, or need anything else, please don't
hesitate to let me know.
Sincerely,
Linda Liu
Microsoft Online Community Support

=============== =============== =============== =======
When responding to posts,please "Reply to Group" via
your newsreader so that others may learn and benefit
from your issue.
=============== =============== =============== =======

Dave Booker wrote:

I have a Thread making a callback to a Form function that alters Form data.
Of course, the debugger is telling me, "Cross-thread operation not valid:
Control 'FormTest' accessed from a thread other than the thread it was
created on."

But I am locking before I touch the shared data, so do I actually need to
worry about this, or is it just the debugger being oversimplistic?

Yes, you need to worry about it. UI components have thread affinity -
they really, really shouldn't be touched except on their own thread.
(Aside from the calls to CreateGraphics, InvokeRequired, BeginInvoke
and Invoke.)

One further note - you appear to be passing string references by
reference without using the by-ref semantics. Is there a reason for
this? You may be unaware of how parameter passing works. See
http://www.pobox.com/~skeet/csharp/parameters.html

Jon

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linda Liu [MSFT] wrote:

delegate void WriteOutDelegat e(ref string Payload);
void test_Callback(r ef string Payload)
{
object[] args = new object[1]{Payload};
this.Invoke(new WriteOutDelegat e(WriteOut),arg s);
}
That also, rather usefuly, helped me resolve getting my head around
the SerialPinChange dEventHandler and using Invoke() when you need to
modify Form UI elements.

So thanks from me for coincidental assistance :)
Sincerely,
Linda Liu
Microsoft Online Community Support

- --
Chris Crowther
Developer
J&M Crowther Ltd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFESJh8z8b l0gyT/hERAswcAKCQJ53B UPhJL1GCFd5qfkF F6b9ZBgCeO3nN
mkl2xlQQsE/9WnHUsRJr+gA=
=22sA
-----END PGP SIGNATURE-----

So I obviously don't understand something important about locking. It looks
to me like the only way the other thread can touch the Form control is
through the TestFunction, and the TestFunction locks the entire object until
the Form text is changed. How could this possibly go wrong?

And would your answer be different if I make either TestFunction() or
WriteOut() static?
"Mattias Sjögren" wrote:

Dave,

But I am locking before I touch the shared data, so do I actually need to
worry about this, or is it just the debugger being oversimplistic?

Yes the warning is right. You should only access Winforms controls
from the thread they were created on. Lock doesn't help here.
Mattias

--
Mattias Sjögren [C# MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

Thank you for this response. But I am obviously failing to understand what's
going on behind the scenes:

"Linda Liu [MSFT]" wrote:

Access to Windows Forms controls is not inherently thread safe. If you have
two or more threads manipulating the state of a control, it is possible to
force the control into an inconsistent state. Other thread-related bugs are
possible as well, including race conditions and deadlocks. It is important
to ensure that access to your controls is done in a thread-safe way.
Given that my private WriteOut() method is only called in a locked
condition, and (let us assume) is guaranteed to return, could you give an
example of any unsafe multi-threading effects that could be achieved on this
class?

To make the access to your controls in a thread-safe way, you should use
the Invoke method of the control. The following is a sample.

delegate void WriteOutDelegat e(ref string Payload);
void test_Callback(r ef string Payload)
{
object[] args = new object[1]{Payload};
this.Invoke(new WriteOutDelegat e(WriteOut),arg s);
}

private void WriteOut(ref string Payload)
{
this.Text = Payload;
}

I thought Invoke is just a means of reflection. What is it about this
construct that ensures thread safety?

To me it just looks like a hideous kludge ... and I can't even understand
how it could help.

Uh oh ... it must be worse than I thought. I migrated from C++ to C# over a
year ago, and I thought I had this straight, but I don't understand what
you're saying even afer rereading your parameters.html page.

Just to be clear, in my example, every function call in the callback loop
uses "ref string" arguments. In this case I am not modifying the string
values and so the only reason to do this, I thought, was performance -- to
avoid making copies of very large strings. Thinking about it further I
suppose that since strings are immutable reference types, then they are
passed by reference anyway and I wouldn't incur any performance penalty
unless I tried to modify them, in which case a new string would be created
and I would just be causing the original string to be replaced by it.

Is this what you were referring to when you say I am "passing string
references by
reference without using the by-ref semantics," or am I committing an actual
mistake of some sort in this example?
"Jon Skeet [C# MVP]" wrote:

One further note - you appear to be passing string references by
reference without using the by-ref semantics. Is there a reason for
this? You may be unaware of how parameter passing works. See
http://www.pobox.com/~skeet/csharp/parameters.html

Taking out a lock on the form is completely irrelevant to thread-affinity.
It isn't the debugger being over-simplistic: rather, the runtime (correctly)
catching your incorrect usage. What you are trying to do will not work, so
stop trying to do it. You *need* to .Invoke() or .BeginInvoke() back to the
owning thread before you update the UI. Linda's response seems pretty
comprehensive, else read MSDN / google.

And for reference, lock(this) is often a bad idea, as it allows objects code
of your scope to *without realising it* share a lock with you; a better
approach is to lock on a dedicated handy object, which you may (or may not)
choose to publicly expose for other callers to sync against; at least if
they lock(something. SyncLock) then they expect you to be using that lock
too.

Marc

Typo:

as it allows objects code of your scope should beas it allows objects out of you scope

i.e. external code may want to sync itself using your object as the lock (no
technical reason why it shouldn't)

Marc