468,119 Members | 1,781 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,119 developers. It's quick & easy.

Worker Threads and Events

I'm working on a class that needs to be called from a windows form, do it's
work, and then, show progress back to the main form. I'm well aware that
worker threads need to call Invoke for updates to the main thread to be
threadsafe. I want to make this worker class I'm writing a self contained
assembly so that other's can drop it into their projects. My question is:

How can I NOT force those implementing my class to have to call Invoke? Is
there a way I can do that within my class so that the progress returned is
safe to use on the main thread? What's the best way to signal that progress
has been made, an event? or some type of callback? Can I do this with
triggering an event from my worker class and listened to by the main thread,
or are events not threadsafe either?
Thanks for your help.

Jacob
Nov 16 '05 #1
3 3072
Never mind, I answered my own question. I realized that the class I'm
writing donsn't really try an make any calls back to the main thread on a
different thread. The class I wrote is handling threaded operations
asynchronously and only signalling events from the portions of the code that
are blocking. For example.

public delegate void ProgressEventHandler(object sender, ProgressEventArgs
e);

public class MyClass
{
public event ProgressEventHandler Progress;

public void DoWork()
{
WebRequest request = WebRequest.Create(new
Uri("http://www.cnn.com"));
request.BeginGetResponse(new AsyncCallback(WorkCallback), request);
}

public void WorkCallback(IAsyncResult result)
{
WebRequest request = (WebRequest)result.AsyncState;
WebResponse response = request.EndGetResponse(result)

// This event is still being raised on the main thread.
if(Progress != null)
Progress(this, new ProgressEventArgs()):
}
}
I just realized that I'm actually sending the Progress event from a portion
of the code that is blocking. All the threaded work is going on between the
DoWork and WorkCallback methods, but calls within those methods should be
safe. So, implementers of my class should be able to subscribe to the
Progress event without fear that it will cause their main thread to throw an
exception. Correct me if I'm wrong.
Jacob


"Jacob" <ja**********@REMOVETHIShotmail.com> wrote in message
news:y_Tdc.6363$es.1144@fed1read02...
I'm working on a class that needs to be called from a windows form, do it's work, and then, show progress back to the main form. I'm well aware that
worker threads need to call Invoke for updates to the main thread to be
threadsafe. I want to make this worker class I'm writing a self contained
assembly so that other's can drop it into their projects. My question is:

How can I NOT force those implementing my class to have to call Invoke? Is there a way I can do that within my class so that the progress returned is
safe to use on the main thread? What's the best way to signal that progress has been made, an event? or some type of callback? Can I do this with
triggering an event from my worker class and listened to by the main thread, or are events not threadsafe either?
Thanks for your help.

Jacob

Nov 16 '05 #2
First of all, I have an article based on an MSDN Magazine article that does
a log of what you are talking about. Have a look at these url's:

http://msdn.microsoft.com/msdnmag/is...g/default.aspx
http://www.mag37.com/csharp/articles...x.html?tabid=8

The idea in the above articles is that if the object subscribing to your
class' events implements ISynchronizeInvoke, then you can always send your
events back on the main thread of the subscriber. This method works well if
you know that the subscriber is a Control (since those all implement
ISynchronizeInvoke).

http://msdn.microsoft.com/library/de...classtopic.asp

Second, to answer your question, you are incorrect in your assumption below.
I've modified your program slightly to show this. You'll see the main thread
sleep 5 seconds after beginning the request. While the main thread is
sleeping, the second thread will complete the request and print something
to the screen. Only then will the first thread actually finish. (You might
need to change the delay to 10 seconds, depending upon how long it takes to
get the cnn.com request).

Hope that helps you out. If you have further questions, feel free to follow
up on this newsgroup.

Mike Mayer, C# MVP
mi**@mag37.com
http://www.mag37.com/csharp/

using System;
using System.Net;
using System.Threading;

public class MyClass
{

public void DoWork()
{
WebRequest request = WebRequest.Create(new Uri("http://www.cnn.com"));
request.BeginGetResponse(new AsyncCallback(WorkCallback), request);
Console.WriteLine("Began request, sleeping 5 seconds");
Thread.Sleep(5000);
Console.WriteLine("Finished sleeping");

}

public void WorkCallback(IAsyncResult result)
{
WebRequest request = (WebRequest)result.AsyncState;
WebResponse response = request.EndGetResponse(result);

// on 2nd thread
Console.WriteLine("Completed request");
}

public static void Main()
{
MyClass myclass = new MyClass();
myclass.DoWork();

}
}


"Jacob" <ja**********@REMOVETHIShotmail.com> wrote in message
news:SpUdc.6366$es.857@fed1read02...
Never mind, I answered my own question. I realized that the class I'm
writing donsn't really try an make any calls back to the main thread on a
different thread. The class I wrote is handling threaded operations
asynchronously and only signalling events from the portions of the code that are blocking. For example.

public delegate void ProgressEventHandler(object sender, ProgressEventArgs
e);

public class MyClass
{
public event ProgressEventHandler Progress;

public void DoWork()
{
WebRequest request = WebRequest.Create(new
Uri("http://www.cnn.com"));
request.BeginGetResponse(new AsyncCallback(WorkCallback), request); }

public void WorkCallback(IAsyncResult result)
{
WebRequest request = (WebRequest)result.AsyncState;
WebResponse response = request.EndGetResponse(result)

// This event is still being raised on the main thread.
if(Progress != null)
Progress(this, new ProgressEventArgs()):
}
}
I just realized that I'm actually sending the Progress event from a portion of the code that is blocking. All the threaded work is going on between the DoWork and WorkCallback methods, but calls within those methods should be
safe. So, implementers of my class should be able to subscribe to the
Progress event without fear that it will cause their main thread to throw an exception. Correct me if I'm wrong.
Jacob


"Jacob" <ja**********@REMOVETHIShotmail.com> wrote in message
news:y_Tdc.6363$es.1144@fed1read02...
I'm working on a class that needs to be called from a windows form, do

it's
work, and then, show progress back to the main form. I'm well aware that worker threads need to call Invoke for updates to the main thread to be
threadsafe. I want to make this worker class I'm writing a self contained assembly so that other's can drop it into their projects. My question is:
How can I NOT force those implementing my class to have to call Invoke?

Is
there a way I can do that within my class so that the progress returned is safe to use on the main thread? What's the best way to signal that

progress
has been made, an event? or some type of callback? Can I do this with
triggering an event from my worker class and listened to by the main

thread,
or are events not threadsafe either?
Thanks for your help.

Jacob


Nov 16 '05 #3
Thank you for that clearer explanation. I've actually read your MSDN
article several times before, but there's nothing like getting it from the
horse's mouth. :)
Jacob
"Michael Mayer [C# MVP]" <mi**@mag37.com> wrote in message
news:uc**************@TK2MSFTNGP10.phx.gbl...
First of all, I have an article based on an MSDN Magazine article that does a log of what you are talking about. Have a look at these url's:

http://msdn.microsoft.com/msdnmag/is...g/default.aspx
http://www.mag37.com/csharp/articles...x.html?tabid=8

The idea in the above articles is that if the object subscribing to your
class' events implements ISynchronizeInvoke, then you can always send your
events back on the main thread of the subscriber. This method works well if you know that the subscriber is a Control (since those all implement
ISynchronizeInvoke).

http://msdn.microsoft.com/library/de...classtopic.asp
Second, to answer your question, you are incorrect in your assumption below. I've modified your program slightly to show this. You'll see the main thread sleep 5 seconds after beginning the request. While the main thread is
sleeping, the second thread will complete the request and print something
to the screen. Only then will the first thread actually finish. (You might
need to change the delay to 10 seconds, depending upon how long it takes to get the cnn.com request).

Hope that helps you out. If you have further questions, feel free to follow up on this newsgroup.

Mike Mayer, C# MVP
mi**@mag37.com
http://www.mag37.com/csharp/

using System;
using System.Net;
using System.Threading;

public class MyClass
{

public void DoWork()
{
WebRequest request = WebRequest.Create(new Uri("http://www.cnn.com"));
request.BeginGetResponse(new AsyncCallback(WorkCallback), request);
Console.WriteLine("Began request, sleeping 5 seconds");
Thread.Sleep(5000);
Console.WriteLine("Finished sleeping");

}

public void WorkCallback(IAsyncResult result)
{
WebRequest request = (WebRequest)result.AsyncState;
WebResponse response = request.EndGetResponse(result);

// on 2nd thread
Console.WriteLine("Completed request");
}

public static void Main()
{
MyClass myclass = new MyClass();
myclass.DoWork();

}
}


"Jacob" <ja**********@REMOVETHIShotmail.com> wrote in message
news:SpUdc.6366$es.857@fed1read02...
Never mind, I answered my own question. I realized that the class I'm
writing donsn't really try an make any calls back to the main thread on a
different thread. The class I wrote is handling threaded operations
asynchronously and only signalling events from the portions of the code that
are blocking. For example.

public delegate void ProgressEventHandler(object sender, ProgressEventArgs e);

public class MyClass
{
public event ProgressEventHandler Progress;

public void DoWork()
{
WebRequest request = WebRequest.Create(new
Uri("http://www.cnn.com"));
request.BeginGetResponse(new AsyncCallback(WorkCallback),

request);
}

public void WorkCallback(IAsyncResult result)
{
WebRequest request = (WebRequest)result.AsyncState;
WebResponse response = request.EndGetResponse(result)

// This event is still being raised on the main thread.
if(Progress != null)
Progress(this, new ProgressEventArgs()):
}
}
I just realized that I'm actually sending the Progress event from a

portion
of the code that is blocking. All the threaded work is going on between

the
DoWork and WorkCallback methods, but calls within those methods should be safe. So, implementers of my class should be able to subscribe to the
Progress event without fear that it will cause their main thread to throw an
exception. Correct me if I'm wrong.
Jacob


"Jacob" <ja**********@REMOVETHIShotmail.com> wrote in message
news:y_Tdc.6363$es.1144@fed1read02...
I'm working on a class that needs to be called from a windows form, do it's
work, and then, show progress back to the main form. I'm well aware

that worker threads need to call Invoke for updates to the main thread to be threadsafe. I want to make this worker class I'm writing a self contained assembly so that other's can drop it into their projects. My question is:
How can I NOT force those implementing my class to have to call
Invoke? Is
there a way I can do that within my class so that the progress

returned is safe to use on the main thread? What's the best way to signal that

progress
has been made, an event? or some type of callback? Can I do this with
triggering an event from my worker class and listened to by the main

thread,
or are events not threadsafe either?
Thanks for your help.

Jacob



Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by spammy | last post: by
3 posts views Thread by Jacob | last post: by
4 posts views Thread by Brian Keating EI9FXB | last post: by
7 posts views Thread by Charles Law | last post: by
13 posts views Thread by didacticone | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.