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

Firing events from multiple threads

P: n/a
I have a class that writes data to the serial port and has a separate thread
to read data from the same port. Typically the main thread writes requests
to the serial port and then returns to the caller. The read thread waits for
a response while the application continues running. When a response is
received, I want to fire an event. But, I don't want the read thread to
raise the event because the event could spawn a whole set of new processing
by the application. I'd like the read thread to buffer the data and then go
back to reading. How can I signal the main thread to raise the event once
the data is buffered?
Nov 21 '05 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Look in ManualResetEvent or AutoResetEvent

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

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:5F**********************************@microsof t.com...
I have a class that writes data to the serial port and has a separate
thread
to read data from the same port. Typically the main thread writes
requests
to the serial port and then returns to the caller. The read thread waits
for
a response while the application continues running. When a response is
received, I want to fire an event. But, I don't want the read thread to
raise the event because the event could spawn a whole set of new
processing
by the application. I'd like the read thread to buffer the data and then
go
back to reading. How can I signal the main thread to raise the event once
the data is buffered?

Nov 21 '05 #2

P: n/a
Thanks Some Guy. But, if I don't want my main thread to block waiting for
the event. I'd like the notification to be asynchonous. Otherwise, the
application will no longer process window messages while my class is waiting
for a response.

"Some Guy" wrote:
Look in ManualResetEvent or AutoResetEvent

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

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:5F**********************************@microsof t.com...
I have a class that writes data to the serial port and has a separate
thread
to read data from the same port. Typically the main thread writes
requests
to the serial port and then returns to the caller. The read thread waits
for
a response while the application continues running. When a response is
received, I want to fire an event. But, I don't want the read thread to
raise the event because the event could spawn a whole set of new
processing
by the application. I'd like the read thread to buffer the data and then
go
back to reading. How can I signal the main thread to raise the event once
the data is buffered?


Nov 21 '05 #3

P: n/a
Hint: Control.Invoke Method (Delegate).
I think you can figure it out if you understand Control.Invoke Method
(Delegate).

"TrtnJohn" wrote:
I have a class that writes data to the serial port and has a separate thread
to read data from the same port. Typically the main thread writes requests
to the serial port and then returns to the caller. The read thread waits for
a response while the application continues running. When a response is
received, I want to fire an event. But, I don't want the read thread to
raise the event because the event could spawn a whole set of new processing
by the application. I'd like the read thread to buffer the data and then go
back to reading. How can I signal the main thread to raise the event once
the data is buffered?

Nov 21 '05 #4

P: n/a
You can use another thread to process the data. This way your main thread
won't be blocked. Or you can call BeginInvoke on your main form to call a
function asynchronously. Be aware that using Invoke instead of BeginInvoke
will block until it's finished.

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:47**********************************@microsof t.com...
Thanks Some Guy. But, if I don't want my main thread to block waiting for
the event. I'd like the notification to be asynchonous. Otherwise, the
application will no longer process window messages while my class is
waiting
for a response.

"Some Guy" wrote:
Look in ManualResetEvent or AutoResetEvent

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

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:5F**********************************@microsof t.com...
>I have a class that writes data to the serial port and has a separate
>thread
> to read data from the same port. Typically the main thread writes
> requests
> to the serial port and then returns to the caller. The read thread
> waits
> for
> a response while the application continues running. When a response is
> received, I want to fire an event. But, I don't want the read thread
> to
> raise the event because the event could spawn a whole set of new
> processing
> by the application. I'd like the read thread to buffer the data and
> then
> go
> back to reading. How can I signal the main thread to raise the event
> once
> the data is buffered?


Nov 21 '05 #5

P: n/a
Rulin,

This looks like a good suggestion. But, does this mean my class must
inherit from System.Windows.Forms.Control? You can't do this type of call
otherwise?

"Rulin Hong" wrote:
Hint: Control.Invoke Method (Delegate).
I think you can figure it out if you understand Control.Invoke Method
(Delegate).

"TrtnJohn" wrote:
I have a class that writes data to the serial port and has a separate thread
to read data from the same port. Typically the main thread writes requests
to the serial port and then returns to the caller. The read thread waits for
a response while the application continues running. When a response is
received, I want to fire an event. But, I don't want the read thread to
raise the event because the event could spawn a whole set of new processing
by the application. I'd like the read thread to buffer the data and then go
back to reading. How can I signal the main thread to raise the event once
the data is buffered?

Nov 21 '05 #6

P: n/a
Use your forms BeginInvoke.
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com...
Rulin,

This looks like a good suggestion. But, does this mean my class must
inherit from System.Windows.Forms.Control? You can't do this type of call
otherwise?

"Rulin Hong" wrote:
Hint: Control.Invoke Method (Delegate).
I think you can figure it out if you understand Control.Invoke Method
(Delegate).

"TrtnJohn" wrote:
> I have a class that writes data to the serial port and has a separate
> thread
> to read data from the same port. Typically the main thread writes
> requests
> to the serial port and then returns to the caller. The read thread
> waits for
> a response while the application continues running. When a response is
> received, I want to fire an event. But, I don't want the read thread
> to
> raise the event because the event could spawn a whole set of new
> processing
> by the application. I'd like the read thread to buffer the data and
> then go
> back to reading. How can I signal the main thread to raise the event
> once
> the data is buffered?

Nov 21 '05 #7

P: n/a
Thanks a lot for the help. I am now making good progress on this issue.
But, I am not sure I can just use the Form.BeginInvoke because I am
developing a class library that will be used by multiple Window's
applications. So, I don't really have a form. So far, I can't seem to find
anyway for a class library to do this. Maybe I should be providing a
UserControl instead? But, this can be a problem because I would also like to
expose the same class library to COM because some applications I need to
support are COM based. The plot thickens :(
"Some Guy" wrote:
Use your forms BeginInvoke.
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com...
Rulin,

This looks like a good suggestion. But, does this mean my class must
inherit from System.Windows.Forms.Control? You can't do this type of call
otherwise?

"Rulin Hong" wrote:
Hint: Control.Invoke Method (Delegate).
I think you can figure it out if you understand Control.Invoke Method
(Delegate).

"TrtnJohn" wrote:

> I have a class that writes data to the serial port and has a separate
> thread
> to read data from the same port. Typically the main thread writes
> requests
> to the serial port and then returns to the caller. The read thread
> waits for
> a response while the application continues running. When a response is
> received, I want to fire an event. But, I don't want the read thread
> to
> raise the event because the event could spawn a whole set of new
> processing
> by the application. I'd like the read thread to buffer the data and
> then go
> back to reading. How can I signal the main thread to raise the event
> once
> the data is buffered?


Nov 21 '05 #8

P: n/a
Will the applications that use the library have a form?

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:D2**********************************@microsof t.com...
Thanks a lot for the help. I am now making good progress on this issue.
But, I am not sure I can just use the Form.BeginInvoke because I am
developing a class library that will be used by multiple Window's
applications. So, I don't really have a form. So far, I can't seem to
find
anyway for a class library to do this. Maybe I should be providing a
UserControl instead? But, this can be a problem because I would also like
to
expose the same class library to COM because some applications I need to
support are COM based. The plot thickens :(
"Some Guy" wrote:
Use your forms BeginInvoke.
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com...
> Rulin,
>
> This looks like a good suggestion. But, does this mean my class must
> inherit from System.Windows.Forms.Control? You can't do this type of
> call
> otherwise?
>
> "Rulin Hong" wrote:
>
>> Hint: Control.Invoke Method (Delegate).
>> I think you can figure it out if you understand Control.Invoke Method
>> (Delegate).
>>
>> "TrtnJohn" wrote:
>>
>> > I have a class that writes data to the serial port and has a
>> > separate
>> > thread
>> > to read data from the same port. Typically the main thread writes
>> > requests
>> > to the serial port and then returns to the caller. The read thread
>> > waits for
>> > a response while the application continues running. When a response
>> > is
>> > received, I want to fire an event. But, I don't want the read
>> > thread
>> > to
>> > raise the event because the event could spawn a whole set of new
>> > processing
>> > by the application. I'd like the read thread to buffer the data and
>> > then go
>> > back to reading. How can I signal the main thread to raise the
>> > event
>> > once
>> > the data is buffered?


Nov 21 '05 #9

P: n/a
Sometimes they will be. But, I cannot assume that they always will. In some
cases, they may just be window-less processes or even NT services. I am
starting to think that asynchronous processing may not be possible given my
requirements. Instead I may have to stick with synchronous request/reply
processing. In this case, the caller will block until the reply or timeout
occurs. Blocking will cause form based applications to go un-responsive.
But, these applications could use Async method calls and/or
Control.BeginInvoke calls when using my library. Or, better yet, I could
provide this as an optional behavior of my class. (client passes reference
of form to me). Do you have any other ideas?

"Some Guy" wrote:
Will the applications that use the library have a form?

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:D2**********************************@microsof t.com...
Thanks a lot for the help. I am now making good progress on this issue.
But, I am not sure I can just use the Form.BeginInvoke because I am
developing a class library that will be used by multiple Window's
applications. So, I don't really have a form. So far, I can't seem to
find
anyway for a class library to do this. Maybe I should be providing a
UserControl instead? But, this can be a problem because I would also like
to
expose the same class library to COM because some applications I need to
support are COM based. The plot thickens :(
"Some Guy" wrote:
Use your forms BeginInvoke.
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:29**********************************@microsof t.com...
> Rulin,
>
> This looks like a good suggestion. But, does this mean my class must
> inherit from System.Windows.Forms.Control? You can't do this type of
> call
> otherwise?
>
> "Rulin Hong" wrote:
>
>> Hint: Control.Invoke Method (Delegate).
>> I think you can figure it out if you understand Control.Invoke Method
>> (Delegate).
>>
>> "TrtnJohn" wrote:
>>
>> > I have a class that writes data to the serial port and has a
>> > separate
>> > thread
>> > to read data from the same port. Typically the main thread writes
>> > requests
>> > to the serial port and then returns to the caller. The read thread
>> > waits for
>> > a response while the application continues running. When a response
>> > is
>> > received, I want to fire an event. But, I don't want the read
>> > thread
>> > to
>> > raise the event because the event could spawn a whole set of new
>> > processing
>> > by the application. I'd like the read thread to buffer the data and
>> > then go
>> > back to reading. How can I signal the main thread to raise the
>> > event
>> > once
>> > the data is buffered?


Nov 21 '05 #10

P: n/a
You can use a Delegate to call BeginInvoke. This is what you are looking
for.

http://msdn.microsoft.com/library/de...mingsample.asp
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:61**********************************@microsof t.com...
Sometimes they will be. But, I cannot assume that they always will. In
some
cases, they may just be window-less processes or even NT services. I am
starting to think that asynchronous processing may not be possible given
my
requirements. Instead I may have to stick with synchronous request/reply
processing. In this case, the caller will block until the reply or
timeout
occurs. Blocking will cause form based applications to go un-responsive.
But, these applications could use Async method calls and/or
Control.BeginInvoke calls when using my library. Or, better yet, I could
provide this as an optional behavior of my class. (client passes
reference
of form to me). Do you have any other ideas?

"Some Guy" wrote:
Will the applications that use the library have a form?

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:D2**********************************@microsof t.com...
> Thanks a lot for the help. I am now making good progress on this
> issue.
> But, I am not sure I can just use the Form.BeginInvoke because I am
> developing a class library that will be used by multiple Window's
> applications. So, I don't really have a form. So far, I can't seem to
> find
> anyway for a class library to do this. Maybe I should be providing a
> UserControl instead? But, this can be a problem because I would also
> like
> to
> expose the same class library to COM because some applications I need
> to
> support are COM based. The plot thickens :(
>
>
> "Some Guy" wrote:
>
>> Use your forms BeginInvoke.
>>
>>
>> "TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
>> news:29**********************************@microsof t.com...
>> > Rulin,
>> >
>> > This looks like a good suggestion. But, does this mean my class
>> > must
>> > inherit from System.Windows.Forms.Control? You can't do this type
>> > of
>> > call
>> > otherwise?
>> >
>> > "Rulin Hong" wrote:
>> >
>> >> Hint: Control.Invoke Method (Delegate).
>> >> I think you can figure it out if you understand Control.Invoke
>> >> Method
>> >> (Delegate).
>> >>
>> >> "TrtnJohn" wrote:
>> >>
>> >> > I have a class that writes data to the serial port and has a
>> >> > separate
>> >> > thread
>> >> > to read data from the same port. Typically the main thread
>> >> > writes
>> >> > requests
>> >> > to the serial port and then returns to the caller. The read
>> >> > thread
>> >> > waits for
>> >> > a response while the application continues running. When a
>> >> > response
>> >> > is
>> >> > received, I want to fire an event. But, I don't want the read
>> >> > thread
>> >> > to
>> >> > raise the event because the event could spawn a whole set of new
>> >> > processing
>> >> > by the application. I'd like the read thread to buffer the data
>> >> > and
>> >> > then go
>> >> > back to reading. How can I signal the main thread to raise the
>> >> > event
>> >> > once
>> >> > the data is buffered?
>>
>>
>>


Nov 21 '05 #11

P: n/a
I got excited when I first saw that too. But, Delegate.BeginInvoke is not
the same as Control.BeginInvoke. There is no thread marshalling. The call
will not occur on the primary UI thread. I found 2 really good articles in
MSDN magazine that describe this problem in detail:

http://msdn.microsoft.com/msdnmag/is...s/default.aspx

and here:

http://msdn.microsoft.com/msdnmag/is...s/default.aspx



"Some Guy" wrote:
You can use a Delegate to call BeginInvoke. This is what you are looking
for.

http://msdn.microsoft.com/library/de...mingsample.asp
"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:61**********************************@microsof t.com...
Sometimes they will be. But, I cannot assume that they always will. In
some
cases, they may just be window-less processes or even NT services. I am
starting to think that asynchronous processing may not be possible given
my
requirements. Instead I may have to stick with synchronous request/reply
processing. In this case, the caller will block until the reply or
timeout
occurs. Blocking will cause form based applications to go un-responsive.
But, these applications could use Async method calls and/or
Control.BeginInvoke calls when using my library. Or, better yet, I could
provide this as an optional behavior of my class. (client passes
reference
of form to me). Do you have any other ideas?

"Some Guy" wrote:
Will the applications that use the library have a form?

"TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
news:D2**********************************@microsof t.com...
> Thanks a lot for the help. I am now making good progress on this
> issue.
> But, I am not sure I can just use the Form.BeginInvoke because I am
> developing a class library that will be used by multiple Window's
> applications. So, I don't really have a form. So far, I can't seem to
> find
> anyway for a class library to do this. Maybe I should be providing a
> UserControl instead? But, this can be a problem because I would also
> like
> to
> expose the same class library to COM because some applications I need
> to
> support are COM based. The plot thickens :(
>
>
> "Some Guy" wrote:
>
>> Use your forms BeginInvoke.
>>
>>
>> "TrtnJohn" <Tr******@discussions.microsoft.com> wrote in message
>> news:29**********************************@microsof t.com...
>> > Rulin,
>> >
>> > This looks like a good suggestion. But, does this mean my class
>> > must
>> > inherit from System.Windows.Forms.Control? You can't do this type
>> > of
>> > call
>> > otherwise?
>> >
>> > "Rulin Hong" wrote:
>> >
>> >> Hint: Control.Invoke Method (Delegate).
>> >> I think you can figure it out if you understand Control.Invoke
>> >> Method
>> >> (Delegate).
>> >>
>> >> "TrtnJohn" wrote:
>> >>
>> >> > I have a class that writes data to the serial port and has a
>> >> > separate
>> >> > thread
>> >> > to read data from the same port. Typically the main thread
>> >> > writes
>> >> > requests
>> >> > to the serial port and then returns to the caller. The read
>> >> > thread
>> >> > waits for
>> >> > a response while the application continues running. When a
>> >> > response
>> >> > is
>> >> > received, I want to fire an event. But, I don't want the read
>> >> > thread
>> >> > to
>> >> > raise the event because the event could spawn a whole set of new
>> >> > processing
>> >> > by the application. I'd like the read thread to buffer the data
>> >> > and
>> >> > then go
>> >> > back to reading. How can I signal the main thread to raise the
>> >> > event
>> >> > once
>> >> > the data is buffered?
>>
>>
>>


Nov 21 '05 #12

This discussion thread is closed

Replies have been disabled for this discussion.