By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,892 Members | 1,238 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,892 IT Pros & Developers. It's quick & easy.

Re: Please suggest a Generic Cross-Thread Safe Invocation technique

P: n/a
On Thu, 26 Jun 2008 03:35:58 -0700, DeveloperX
<ia************@googlemail.comwrote:
Hello, this came up a few days ago, well similar. I suggested
SynchronizationContext briefly, I've found a blog post which explains
the ThreadBarrier pattern and may be of use.

http://blog.quantumbitdesigns.com/20...threadbarrier/

and also

http://blog.quantumbitdesigns.com/20...ier-revisited/
I think these articles are informative and useful food for thought.
However, they don't seem to really be applicable here, and I definitely
disagree with the implication that a) using Invoke() is "polluting the UI
thread" and especially b) that the proposed alternative, using the
SynchronizationContext class, avoids "polluting the UI thread". If
there's a pollution problem (and I don't feel that there is), the
SynchronizationContext approach has exactly the same problem that
Control.Invoke() does (seeing as they both wind up using the same
mechanisms).

In this particular message thread, there is a specific need to execute the
code on the GUI thread. There's no way around that. The simplest, most
straightforward way to do that is to simply call Invoke() with an
anonymous method that contains the code that needs to be executed.

It's good for people to know that SynchronizationContext exists and how to
use it. But in reality, Control.Invoke() (or Control.BeginInvoke()) is
sufficient and perfectly appropriate for most needs.
Peter, Google groups is working in Opera again :D
Yay! :) Still, you might eventually find that using a real newsreader is
better. :)

Pete
Jun 27 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
On Jun 26, 7:30*pm, "Peter Duniho" <NpOeStPe...@nnowslpianmk.com>
wrote:
On Thu, 26 Jun 2008 03:35:58 -0700, DeveloperX *

<ianathomeag...@googlemail.comwrote:
Hello, this came up a few days ago, well similar. I suggested
SynchronizationContext briefly, I've found a blog post which explains
the ThreadBarrier pattern and may be of use.
http://blog.quantumbitdesigns.com/20...ting-the-ui-th...
and also
http://blog.quantumbitdesigns.com/20...g-ui-and-worke...

I think these articles are informative and useful food for thought. *
However, they don't seem to really be applicable here, and I definitely *
disagree with the implication that a) using Invoke() is "polluting the UI*
thread" and especially b) that the proposed alternative, using the *
SynchronizationContext class, avoids "polluting the UI thread". *If *
there's a pollution problem (and I don't feel that there is), the *
SynchronizationContext approach has exactly the same problem that *
Control.Invoke() does (seeing as they both wind up using the same *
mechanisms).

In this particular message thread, there is a specific need to execute the *
code on the GUI thread. *There's no way around that. *The simplest, most *
straightforward way to do that is to simply call Invoke() with an *
anonymous method that contains the code that needs to be executed.

It's good for people to know that SynchronizationContext exists and how to *
use it. *But in reality, Control.Invoke() (or Control.BeginInvoke()) is*
sufficient and perfectly appropriate for most needs.
Peter, Google groups is working in Opera again :D

Yay! *:) *Still, you might eventually find that using a real newsreader is *
better. *:)

Pete
Yep I take that on board, I've been playing with it in a mix of UI and
non UI contexts so it's quite interesting to me. I was semi wrong
about Opera being fixed. It works in standard view, but not tree view.
I'd love to use a real newsreader, but our pesky firewall is in the
way :( Fine at home of course.
Jun 27 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.