Cross thread question .....

[temp2]

Hello,

I have an app that reads data params from a stream and updates
controls accordingly. The stream reader is on a different thread than
the main thread that created the controls. I fully realize it's not
wise, and in some circumstances, not even possible to update the
controls from the stream other than the main stream. I believe there
are two recommended ways to handle this situation.

1. Use Invoke() to "call" an updater method on the main thread from
the stream reader thread.

2. Use the BackgroundWorker class and update controls with the
RunWorkerCompleted event handler.
Question is: Which one is better? I have to update about 75 controls
at a 10Hz rate (10 times a second) so I'm looking for speed here.
TIA

using 2.0, VS2005

 

[Samuel R. Neff]

Use option 3. BeginInvoke() which calls the method on the UI thread
without blocking the stream thread.

HTH,

Sam

 

[Bruce Wood]

Hello,

I have an app that reads data params from a stream and updates
controls accordingly. The stream reader is on a different thread than
the main thread that created the controls. I fully realize it's not
wise, and in some circumstances, not even possible to update the
controls from the stream other than the main stream. I believe there
are two recommended ways to handle this situation.

1. Use Invoke() to "call" an updater method on the main thread from
the stream reader thread.

2. Use the BackgroundWorker class and update controls with the
RunWorkerCompleted event handler.
Question is: Which one is better? I have to update about 75 controls
at a 10Hz rate (10 times a second) so I'm looking for speed here.
TIA

using 2.0, VS2005

Here's another option.

If you _know_ that you're going to be updating the controls rapidly,
10 times a second, as you said, an you're going to do this until, say,
the user presses Cancel or something, you could create an intermediate
area where the values for the controls are stored. So, conceptually,
you have your UI controls, which are displaying results, your stream,
which is reading results to display, and a "neutral zone" where the
results are stored.

Your stream thread just reads results and updates the "neutral zone"
values.

Your UI thread runs in a loop and (at some regular interval) picks up
values from the "neutral zone" and updates all of the contols.

Good points:

No need to marshal calls across threads. The two threads run
independently. I anticipate that this will be a big time saver.

The UI thread can be tuned (UI updates) separately from the stream
thread. In other words, you've decoupled the need for every-input-must-
be-displayed logic.

So... the UI can never "get behind" the updates and have a huge number
of calls build up on its event queue because there are no calls from
the stream thread to the UI thread.

Bad points:

Because input and display are decoupled, any given display may show
inconsistent data. However, if you're really updating 10 times a
second, I doubt that the user will notice.

The "neutral zone" data area must have proper locking done on it, so
that the UI thread doesn't read a value as its being updated by the
stream thread.

You may miss displaying some results, if the stream thread updates a
result twice before the UI thread displays it. Again, I doubt that
your user will notice.

You may do many more UI updates than are necessary. If one UI control
changes frequently while another changes rarely, and if this is
unpredictable, you will be updating all 75 controls every cycle,
because you have no idea what has changed and what hasn't. (This can
be mitigated by taking a snapshot of the "neutral zone" and then
updating the UI from that, giving you a basis for comparison next
time, but that's getting rather complicated, IMHO.)

Anyway... some food for thought.

 

[Robson Siqueira]

Hey,

What if you create a delegate and pass this delegate as a parameter to your
thread? The delegate would be within the same context as the main thread. I
did this already before and works just fine.

 

[Brian Gideon]

Hello,

I have an app that reads data params from a stream and updates
controls accordingly. The stream reader is on a different thread than
the main thread that created the controls. I fully realize it's not
wise, and in some circumstances, not even possible to update the
controls from the stream other than the main stream. I believe there
are two recommended ways to handle this situation.

1. Use Invoke() to "call" an updater method on the main thread from
the stream reader thread.

2. Use the BackgroundWorker class and update controls with the
RunWorkerCompleted event handler.
Question is: Which one is better? I have to update about 75 controls
at a 10Hz rate (10 times a second) so I'm looking for speed here.
TIA

using 2.0, VS2005

Hello,

I agree with Bruce on this one. Have your UI thread poll a shared
data structure that contains the data coming in from the stream. This
will be both faster (I think) and less risky since it eliminates the
possibility of the worker thread overrunning the UI thread with
BeginInvoke/Invoke calls.

Brian

 

[Bruce Wood]

Just to clarify, you would still have to call the delegate using
Invoke or BeginInvoke. You can't just call it outright, as it would
then run in the context of the background thread.

There's nothing about a delegate that ensures that it always runs on a
particular thread; a delegate is just a pointer to a method to run,
nothing more.