|
|
You're in the
dotnet windows forms
group:Threading Advice Quick Question
dotnet windows forms:
[quoted text, click to view]
On 29 Jun 2006 01:42:38 -0700, Mark wrote: > Hi I have a non UI set of classes which do bits and pieces like getting > file lists, generating xml etc. I figured on doing some of these > processes on seperate threads. These wouldnt be called by the UI they > would be controlled by the objects themselves. My question is simply > whats the correct way to notify completion back to the object that > called it. I have used control.invoke in the past but the objects arent > controls as such although I could make them I guess. Just looking for > some advice on best practice. If your classes are general non-UI classes that performs asyncronous operations (let's call these classes the business layer) and notify the client of their completion via callback methods then the clients of these classes should expect these callbacks to be called in a worker thread and take appropriate steps to deal with it. This is how all the classes in the ..NET Framework that provide asyncronous methods do it (they have BeginXXX methods that take an AsyncCallback delegate and they invoke the callback method in a thread from the thread pool). In other words, it is in your UI layer that you should marchall the callback method to the UI thread if you need to access any UI control. Your business layer does not have any knowledge of the constraints of the UI when it comes to multi-threading and should not bother about it. Now, if you really want to interleave the UI and the business layers, you could pass a Control object in the constructor of your business classes allowing them to call Invoke() or BeginInvoke() on it in order to invoke
Hi I have a non UI set of classes which do bits and pieces like getting
file lists, generating xml etc. I figured on doing some of these processes on seperate threads. These wouldnt be called by the UI they would be controlled by the objects themselves. My question is simply whats the correct way to notify completion back to the object that called it. I have used control.invoke in the past but the objects arent controls as such although I could make them I guess. Just looking for some advice on best practice. Cheers
Hi Mehdi,
You can do this by using a Delegate, just invoke the delegate after finishing the work. The method pointed to by the delegate can be in the same class where you do the work. Hope this helps. "Mehdi" <vioccc@REMOVEME.gmail.com> escribió en el mensaje news:1m5l6ml0qcmmo$.iiuuejrh191v.dlg@40tude.net... [quoted text, click to view] > On 29 Jun 2006 01:42:38 -0700, Mark wrote: > >> Hi I have a non UI set of classes which do bits and pieces like getting >> file lists, generating xml etc. I figured on doing some of these >> processes on seperate threads. These wouldnt be called by the UI they >> would be controlled by the objects themselves. My question is simply >> whats the correct way to notify completion back to the object that >> called it. I have used control.invoke in the past but the objects arent >> controls as such although I could make them I guess. Just looking for >> some advice on best practice. > > If your classes are general non-UI classes that performs asyncronous > operations (let's call these classes the business layer) and notify the > client of their completion via callback methods then the clients of these > classes should expect these callbacks to be called in a worker thread and > take appropriate steps to deal with it. This is how all the classes in the > .NET Framework that provide asyncronous methods do it (they have BeginXXX > methods that take an AsyncCallback delegate and they invoke the callback > method in a thread from the thread pool). In other words, it is in your UI > layer that you should marchall the callback method to the UI thread if you > need to access any UI control. Your business layer does not have any > knowledge of the constraints of the UI when it comes to multi-threading > and > should not bother about it. > > Now, if you really want to interleave the UI and the business layers, you > could pass a Control object in the constructor of your business classes > allowing them to call Invoke() or BeginInvoke() on it in order to invoke > their callback methods in the UI thread.
[quoted text, click to view]
Mark wrote: > Hi I have a non UI set of classes which do bits and pieces like getting > file lists, generating xml etc. I figured on doing some of these > processes on seperate threads. These wouldnt be called by the UI they > would be controlled by the objects themselves. My question is simply > whats the correct way to notify completion back to the object that > called it. I have used control.invoke in the past but the objects arent > controls as such although I could make them I guess. Just looking for > some advice on best practice. > > Cheers > Here's the thread class i wrote to support callback. Its imple and esay to extend if needed: namespace MySystem { public delegate void MyThreadStart(); public class MyThread { public event EventHandler ThreadFinished; protected MyThreadStart m_tsThreadStart; public MyThread(MyThreadStart tsThreadStart) { m_tsThreadStart = tsThreadStart; } public void Start() { m_tsThreadStart.BeginInvoke(new AsyncCallback(CallBack), null); } private void CallBack(IAsyncResult res) { if (ThreadFinished != null) ThreadFinished(this, EventArgs.Empty); } } } And when you create that thread object you just subscribe to its ThreadFinished event which will fire when the thread is done. One note: maybe i'm mistaken but i think that callback will fire in context of that worker thread - just something to be aware of especially if you deal with UI. Hope it helps,
Easiest way to do this is to wrap your current calculation or data-bound
methods with a delegate. Call BeginInvoke on the delegate and pass a delegate to a method that will be called upon completion of the asynchronous method. In this method, call EndInvoke to retrieve the results of the async op. I wrote a little article for CodeProject about it: http://www.codeproject.com/useritems/Async_Ops_and_Delegates.asp Check out the code for the third rendezvous technique. It shows you how to handle EndInvoke properly. I'd also suggest you get 'CLR Via C#', which has lots of good info about asynchronous ops and the various pitfalls you face when using them. [quoted text, click to view] "Mark" wrote:
> Hi I have a non UI set of classes which do bits and pieces like getting > file lists, generating xml etc. I figured on doing some of these > processes on seperate threads. These wouldnt be called by the UI they > would be controlled by the objects themselves. My question is simply > whats the correct way to notify completion back to the object that > called it. I have used control.invoke in the past but the objects arent > controls as such although I could make them I guess. Just looking for > some advice on best practice. > > Cheers >
[quoted text, click to view]
On Fri, 30 Jun 2006 00:05:18 -0400, MuZZy wrote: > Here's the thread class i wrote to support callback. Its imple and esay > to extend if needed: [...] > public delegate void MyThreadStart(); > public class MyThread > { > protected MyThreadStart m_tsThreadStart; [...] > public void Start() > { > m_tsThreadStart.BeginInvoke(new AsyncCallback(CallBack), null); > } [...] > } > And when you create that thread object you just subscribe to its > ThreadFinished event which will fire when the thread is done. There's like a problem with your helper class. Typically, when somebody wants to create their own thread instead of using a thread from the ThreadPool (which is much more efficient), this is because they want to do some long running operation. Doing a long running operation in a thread taken from the ThreadPool is a no-no as you might end up starving the ThreadPool. Yet, that's what you are doing in your class: m_tsThreadStart.BeginInvoke(new AsyncCallback(CallBack), null); Calling BeginInvoke() on a delegate doesn't create a new thread but causes the fonction represented by the delegate to be executed in a thread from the ThreadPool. This wouldn't be a problem if you made it clear that your Start() method actually invoked the supplied delegate in a thread from the ThreadPool and *not* from a new thread. But instead, you have given your class the very misleading name "MyThread" which leads users to think that this is just a wrapper for the Thread class; the name of its event ("ThreadFinished") adds to the confusion. I think that you should either create a new thread in your Start() method instead of using the ThreadPool or rename your class and make it very clear in the doc and explanation that
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 |