Thread A notifying Thread B of an Event

Hehe, I have to ask, why much less lines?

Am I the black sheep of the newsgroup?
"Cor" <no*@non.com> wrote in message
news:OH******** ********@TK2MSF TNGP11.phx.gbl. ..

Hi CJ,

I did not know how to write this, now I know, I was mixing you up with
someone totally different sometimes active in this newsgroup.

Stuppid me, I would have written it in a different way normaly to you.

(much less lines)

But mistakes are lessons

:-))

Cor

Hi CJ,

I reviewed the replies that you posted here. My understanding is that you
are suggesting using a EventHandler to handle an event fired from another
thread. If I miss something here, or if I misunderstood any thing, please
correct me.

As far as I know, the EventHandler delegate doesn't mashal a call from a
thread to another. Therefore if you raise a event from thread A, the event
handler will be executed in thread B regardless in which thread that object
is created.

Bob, I saw that Peter suggested to use synchronization objects. I believe
this is viable. Basically you have to check the status of the
synchronization objects in thread A, and change the status of the
synchronization objects from thread B. When thread A founds status of the
synchronization object changes, it does what ever it needs.

CJ's posts do remind me of another approach to the problem. Usually we can
use MethodInvoker delegate on Windows Controls to make cross thread call.
And the code snippet shows how:

Public Class DataForm1
Inherits System.Windows. Forms.Form

Private frm As DataForm1

'Code Omitted

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim t1 As Thread = New Thread(New ThreadStart(Add ressOf
ThreadProc1))
Dim t2 As Thread = New Thread(New ThreadStart(Add ressOf
ThreadProc2))

t1.Start()
t2.Start()

t1.Join()
t2.Join()
End Sub

Public Sub Thread2NotifyTh read1()
Debug.WriteLine ("Thread2Notify Thread1, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
End Sub

<STAThread()> _
Protected Sub ThreadProc1()
Debug.WriteLine ("ThreadProc 1, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
frm = New DataForm1

Dim sMsg As String = "frm.Handle : " & frm.Handle.ToSt ring()
Debug.WriteLine (sMsg)
Dim i As Integer
For i = 0 To 1000
'Do your work here.
Thread.Sleep(10 )
Application.DoE vents()
Next
End Sub
<STAThread()> _
Protected Sub ThreadProc2()
Debug.WriteLine ("ThreadProc 2, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
Thread.Sleep(50 0) 'Wait till Thread 1 creates Frm
frm.Invoke(New MethodInvoker(A ddressOf frm.Thread2Noti fyThread1))
End Sub

Thread 1 creates a Form1 object frm, and do its work in a loop. In the loop
it calls Application.DoE vents() so that the frm's method can be called by
Thread 2. In the thread 2, it uses MethodInvoker to execute method on the
frm object.

This approach is not intuitive as using synchronization objects. Anyway it
does looks simpler and easier to code.

Best regards,
David Yuan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

David,

Hi CJ,

I reviewed the replies that you posted here. My understanding is that you
are suggesting using a EventHandler to handle an event fired from another
thread. If I miss something here, or if I misunderstood any thing, please
correct me.

I was using eventhandler delegate as an example. Not necessarily saying to
use that one in particular but the idea of delegates in general. As I
understood it (and I could be wrong, but would like clarification if so) was
that a delegate would marshal the call across threads.

Now, my reasoning, which is very important. Take for example you have a
status window with a textbox ( or anything inheriting
system.windows. forms.control). Now you start X # of threads... So you
invoke a method on ClassA... ClassA has an event called myStatusEvent as
myStatusEventHa ndler. It has one property, thats message( for
simplicity)... so we have.

Public Class ClassA

Public Event myStatusEvent as myStatusEventHa ndler

private _otherClass as ClassA 'used for referencing other thread object

public property OtherClass as ClassA
Get
return _otherClass
End get
set (value as ClassA)
_otherClass = value
Addhandler _otherClass.myS tatusEvent, new MyStatusEventHa ndler _
(AddressOf onStatusEvent)
end set
end property
Public Sub Execute()

...... do your stuff...

RaiseEvent myStatusEvent(m e, new StatusEventArgs ("Thread Raised
Event..."))

End Sub

private sub onStatusEvent (sender as object, e as StatusEventArgs )
... (delegate should marshal event from other thread??? because its
raised within execute??) This is where I think I may be
confused.
end sub

As far as I know, the EventHandler delegate doesn't mashal a call from a
thread to another. Therefore if you raise a event from thread A, the event
handler will be executed in thread B regardless in which thread that object is created.

Bob, I saw that Peter suggested to use synchronization objects. I believe
this is viable. Basically you have to check the status of the
synchronization objects in thread A, and change the status of the
synchronization objects from thread B. When thread A founds status of the
synchronization object changes, it does what ever it needs.

CJ's posts do remind me of another approach to the problem. Usually we can
use MethodInvoker delegate on Windows Controls to make cross thread call.
I think this is where I was going with it... The reason being, I remember
coming across a similar problem when doing the status events and needing to
do a cross thread call to write to the owning thread... (the thread that
owns the control).
But nonetheless... A delgate is a delegate... So should it matter if the
delegate is a MethodInvoker Delegate??? Is there something I'm missing?
Because what your writing is just another way of putting my reasoning as I
see it.

and in no way is this meant to be bad. But like most people here I want to
be a better programmer, so if I'm doing something wrong, I want to know.

And my harshness towards Peter? I just can't get over the incessent "Thanks
for posting to the community" (I know I'm not the only one) and constantly
restating the question. I just expect someone from the dcompany that
developed the product to provide a better solution than a 14 year old.

That and I hate timers... especially for synchronization (I'm on a project
right now that I'm re-writing in which case they did asynchronous calls with
a timer... and no syncronization on the variable... it was a financial
trading application.. so imagine my paranoia.. =))
And the code snippet shows how:

Public Class DataForm1
Inherits System.Windows. Forms.Form

Private frm As DataForm1

'Code Omitted

Private Sub Button1_Click(B yVal sender As System.Object, ByVal e As
System.EventArg s) Handles Button1.Click
Dim t1 As Thread = New Thread(New ThreadStart(Add ressOf
ThreadProc1))
Dim t2 As Thread = New Thread(New ThreadStart(Add ressOf
ThreadProc2))

t1.Start()
t2.Start()

t1.Join()
t2.Join()
End Sub

Public Sub Thread2NotifyTh read1()
Debug.WriteLine ("Thread2Notify Thread1, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
End Sub

<STAThread()> _
Protected Sub ThreadProc1()
Debug.WriteLine ("ThreadProc 1, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
frm = New DataForm1

Dim sMsg As String = "frm.Handle : " & frm.Handle.ToSt ring()
Debug.WriteLine (sMsg)
Dim i As Integer
For i = 0 To 1000
'Do your work here.
Thread.Sleep(10 )
Application.DoE vents()
Next
End Sub
<STAThread()> _
Protected Sub ThreadProc2()
Debug.WriteLine ("ThreadProc 2, Thread id: " +
Thread.CurrentT hread.GetHashCo de().ToString() )
Thread.Sleep(50 0) 'Wait till Thread 1 creates Frm
frm.Invoke(New MethodInvoker(A ddressOf frm.Thread2Noti fyThread1))
End Sub

Thread 1 creates a Form1 object frm, and do its work in a loop. In the loop it calls Application.DoE vents() so that the frm's method can be called by
Thread 2. In the thread 2, it uses MethodInvoker to execute method on the
frm object.

This approach is not intuitive as using synchronization objects. Anyway it
does looks simpler and easier to code.

Best regards,
David Yuan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Using VS 2003, Vb, MSDE...

Every now and then you open a hornet's nest. Thanks for all the replies,
they have been very helpful, although many of the responses harshly disagree
with each other. We all want to be better programmers.

These are my results of Using RaiseEvents vs Using A System.Timers.T imer.

Using RaiseEvents - You can indeed create a horizontal RaiseEvent that is
caught by an event handler in an unrelated parellel thread. Since I only
wanted certain threads to catch the event, after all threads were created, I
used code like below to put the add handler the the specific thread where it
was needed. All threads are added to gsArray_of_Trun k_Threads as they are
created. The Event Shutdown_Trunk_ Thread_Non_Grac efully just means you
hang up on any caller currently talking on that trunk. So, below puts the
add handler in thread 1 only.

AddHandler Me.Shutdown_Tru nk_Thread_Non_G racefully, AddressOf
gsArray_of_Trun k_Threads(1).Sh utdown_Trunk_Th read_Non_Gracef ully_EventHandl e
r

I also tried different ways of doing the above, all with the same results
below.

When raised by thread 0, the event is caught by thread 1. However, I have
discovered that 1) the delagate
Shutdown_Trunk_ Thread_Non_Grac efully_EventHan dler is running under thread 0
based on the debug threading window and 2) the delagate method is totally
unaware of any of thread 1 instantiations (particcularly Com Object
instantiations) in the Declarations section. All of these trunk threads are
running in ApartmentState. STA, which is a requirement of Intel's Dialogic
cards. So, if I call the Dialogic card command to go on hook to hang up, it
fails, essentially saying no trunk was ever assigned, which of course isn't
true, since someone is talking on that trunk right now.

Is this what you would expect?

Using A System.Timers.T imer- If you do the same thing via a timer on thread
1 (i.e. execute Shutdown_Trunk_ Thread_Non_Grac efully_EventHan dler or
equivalent), the timer is 1) running under a seperate thread based on the de
bug threading window (like the RaiseEvent in option above), but 2) it DOES
seem to
be aware of all instantiations of that thread 1 in its declarations section
and works fine.

Is this what you would expect?

Anyway, it looks like timer is the way to go in my case.

I look forward to your replies and appreciate them all.

Thanks!
Bob

Hey bob,

Glad you found a solution the way you wanted.. However, (and thats
completly fine), your addhandler method never uses a delegate...whic h is why
you may still be in the same thread.. Address of simple creates a function
pointer, doesn't delegate across.

but hey, timers work, then timers work, and thats all thats important isn't
it? =)

Good luck,
CJ

"Bob Day" <Bo****@TouchTa lk.net> wrote in message
news:uA******** ********@TK2MSF TNGP12.phx.gbl. ..

Using VS 2003, Vb, MSDE...

Every now and then you open a hornet's nest. Thanks for all the replies,
they have been very helpful, although many of the responses harshly disagree with each other. We all want to be better programmers.

These are my results of Using RaiseEvents vs Using A System.Timers.T imer.

Using RaiseEvents - You can indeed create a horizontal RaiseEvent that is
caught by an event handler in an unrelated parellel thread. Since I only
wanted certain threads to catch the event, after all threads were created, I used code like below to put the add handler the the specific thread where it was needed. All threads are added to gsArray_of_Trun k_Threads as they are
created. The Event Shutdown_Trunk_ Thread_Non_Grac efully just means you
hang up on any caller currently talking on that trunk. So, below puts the
add handler in thread 1 only.

AddHandler Me.Shutdown_Tru nk_Thread_Non_G racefully, AddressOf
gsArray_of_Trun k_Threads(1).Sh utdown_Trunk_Th read_Non_Gracef ully_EventHandl e r

I also tried different ways of doing the above, all with the same results
below.

When raised by thread 0, the event is caught by thread 1. However, I have
discovered that 1) the delagate
Shutdown_Trunk_ Thread_Non_Grac efully_EventHan dler is running under thread 0 based on the debug threading window and 2) the delagate method is totally
unaware of any of thread 1 instantiations (particcularly Com Object
instantiations) in the Declarations section. All of these trunk threads are running in ApartmentState. STA, which is a requirement of Intel's Dialogic
cards. So, if I call the Dialogic card command to go on hook to hang up, it fails, essentially saying no trunk was ever assigned, which of course isn't true, since someone is talking on that trunk right now.

Is this what you would expect?

Using A System.Timers.T imer- If you do the same thing via a timer on thread 1 (i.e. execute Shutdown_Trunk_ Thread_Non_Grac efully_EventHan dler or
equivalent), the timer is 1) running under a seperate thread based on the de bug threading window (like the RaiseEvent in option above), but 2) it DOES
seem to
be aware of all instantiations of that thread 1 in its declarations section and works fine.

Is this what you would expect?

Anyway, it looks like timer is the way to go in my case.

I look forward to your replies and appreciate them all.

Thanks!
Bob

CJ,

I am afraid that delegate is not that magic that it can do the cross-thread
notification stuff for you. ;). I demonstrated how to use the MethodInvoker
delegate in my last post. But magic thing doesn't happen within it. In fact
the cross-thread plumbing work is done by the Control.Invoke method. Note
that in the ThreadProc2, I called frm.Invoke, this method marshals the call
to the thread 1. You can have a look at the MSDN or the link below for more
information:

http://msdn.microsoft.com/library/de...us/cpref/html/
frlrfSystemWind owsFormsControl ClassInvokeTopi c.asp

I totally understand your concern about the cross-thread programming.
Inappropriate usage of it can cause a degrade of the application's
performance, if you are lucky, or a disasterous crash, if you are not. :)

Bob, I understand that you are using a Timer to poll the changes made by
another thread. I believe that the cost of this approach depends on how
much work you need to perform in each poll. If it is easy to check changes
made by another thread each time the Timer fires, this approach should work
fine. However if it is not, you may want to consider using the
synchronization objects. The code snippet below demonstrats how to use a
AutoResetEvent object to notify another thread:

Imports System.Threadin g

Module Module1
Dim AutoEvent As AutoResetEvent
Dim ThreadExitEvent As AutoResetEvent

Public Sub ThreadProc()
Dim workingThreadCo ndition As Integer
For workingThreadCo ndition = 1 To 5
'You may add your working stuff in the loop
Thread.Sleep(10 00)
AutoEvent.Set()
Next

'Singal the main thread that I am exiting
ThreadExitEvent .Set()
Debug.WriteLine ("Worker Threading Exits")
End Sub

Sub Main()
AutoEvent = New AutoResetEvent( False)
ThreadExitEvent = New AutoResetEvent( False)

Dim workingThread As New Thread(AddressO f ThreadProc)
workingThread.S tart()

'We check if the worker thread has exited.
While Not ThreadExitEvent .WaitOne(0, False)
'You may add your working stuff in the loop
'Check if the worker thread has notifications here
If AutoEvent.WaitO ne(0, False) Then
Debug.WriteLine ("woker thread signal fired")
End If
Thread.Sleep(10 00)
End While
'Wait for working thread exit
workingThread.J oin()
Debug.WriteLine ("Main Threading Exits")
End Sub
End Module

Best regards,
David Yuan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi David,

I really do not understand why my messages in this thread are totally
ignored.

I give my opinion that managing threads horizontaly is a not good approach.
In some lines you admit that but I get more and more the idea that you are
trying to make the example from Peter is the right one.

I do not say the example from Peter is wrong (I did not check it, so I
cannot say that), I say the approach is wrong. (Peter did try to give his
best answer to the direct question).

And therefore I think this is not a good advice.

But just my thought about it.

(If you disagree with me and say managing threads horizontally is the best
approach, than I am curious to your answer).

Cor

David,

CJ,

I am afraid that delegate is not that magic that it can do the cross-thread notification stuff for you. ;). I demonstrated how to use the MethodInvoker delegate in my last post. But magic thing doesn't happen within it. In fact the cross-thread plumbing work is done by the Control.Invoke method. Note
that in the ThreadProc2, I called frm.Invoke, this method marshals the call to the thread 1. You can have a look at the MSDN or the link below for more information:

Ok, thats what I was thinking of. I was misunderstandin g the use of a
delegate (sort of). I understand its nothing more than a glorified function
pointer, but I didn't know if it helped marshal the call. I thought I read
a blog (which was probably a mistake taking it as verbatim...) that said
this was true. I don't know, I do a lot of reading in a day. =)

however, the control.invoke was the approach I was trying to communicate. I
remember building an app before that I would throw an exception (can't
remember which one) if I was running a multi-threaded process and notifying
a single control (multi-line text box) of changes within the threads using
events. Because the threads were different, I used a delegate to use
control.invoke. I was just mixed up on what did what and when. =)

So sorry for the confusion. Just want to make sure I get it right.
http://msdn.microsoft.com/library/de...us/cpref/html/ frlrfSystemWind owsFormsControl ClassInvokeTopi c.asp

I totally understand your concern about the cross-thread programming.
Inappropriate usage of it can cause a degrade of the application's
performance, if you are lucky, or a disasterous crash, if you are not. :)

Yes... as many of us have learned by example. =) I just have experience
with timers being incredibly expensive, and after a recent project, in which
case a timer was used for synchronization (if you want to call it that...)
I have a bit of a bad taste for them.

Thanks for your efforts and it is appreciated greatly...
Bob, I understand that you are using a Timer to poll the changes made by
another thread. I believe that the cost of this approach depends on how
much work you need to perform in each poll. If it is easy to check changes
made by another thread each time the Timer fires, this approach should work fine. However if it is not, you may want to consider using the
synchronization objects. The code snippet below demonstrats how to use a
AutoResetEvent object to notify another thread:

Imports System.Threadin g

Module Module1
Dim AutoEvent As AutoResetEvent
Dim ThreadExitEvent As AutoResetEvent

Public Sub ThreadProc()
Dim workingThreadCo ndition As Integer
For workingThreadCo ndition = 1 To 5
'You may add your working stuff in the loop
Thread.Sleep(10 00)
AutoEvent.Set()
Next

'Singal the main thread that I am exiting
ThreadExitEvent .Set()
Debug.WriteLine ("Worker Threading Exits")
End Sub

Sub Main()
AutoEvent = New AutoResetEvent( False)
ThreadExitEvent = New AutoResetEvent( False)

Dim workingThread As New Thread(AddressO f ThreadProc)
workingThread.S tart()

'We check if the worker thread has exited.
While Not ThreadExitEvent .WaitOne(0, False)
'You may add your working stuff in the loop
'Check if the worker thread has notifications here
If AutoEvent.WaitO ne(0, False) Then
Debug.WriteLine ("woker thread signal fired")
End If
Thread.Sleep(10 00)
End While
'Wait for working thread exit
workingThread.J oin()
Debug.WriteLine ("Main Threading Exits")
End Sub
End Module

Best regards,
David Yuan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Thanks for all the info - it was very helpful.
Bob Day

"Bob Day" <Bo****@TouchTa lk.net> wrote in message
news:ub******** ********@TK2MSF TNGP12.phx.gbl. ..

Using VS 2003, VB, MSDE...

There are two threads, A & B, that continously run and are started by Sub
Main. They instantiationsl of identical code. Thread A handles call
activity on telephone line 1 and Thread B handles call activity on telephone line 2. They use a common SQL datasource, but all DataSets are unique to
each thread.

Is there a way for thread A to occasionally communication to thread B that
something has happened? The ideal situation would be for thread A to raise an event that a handler in thread B handles. But, I don't see how to do
that (the raised event would be handled "up the call stack" in Sub Main, not "horizontia lly" by the other thread).

Specifically, thread A has added a row(s) to the common datasource that I
need thread B to know about. I am currently doing it with a timer in thread B that check the common datasource for changes every 15 seconds, which works OK, but am looking for a simpler solution. I have looked at SQL triggers, but don't see how that would alert thread B. I have looked at RaseEvents,
but don't see any help there either.

Any ideas? Do System.Timers. exert a heavy resource usage toll? If not I
may jus stick with the timer method.

Thansk!

Bob

Hi Cor,

I am sorry I didn't reply to you, this is because I am not sure what do you
mean by "horizontal threads" exactly. :)

I did see that in some previous posts that you suggest to use separate data
store for each of the threads. But I am afraid this is not practical in
Bob's programming scenario. It is ideal that every thread has its own
resouces such as data store. However the reality is sometimes you have to
share resouces among threads.

And if we do have to, there are cateories of approaches. The first one is
to to poll the resource constantly, which includes the timer approach. The
other category is to use synchronization objects such as AutoResetEvent to
send notifications between threads.

The Control.Invoke method that I demonstrated is in fact a variant of using
synchronization objects. It is in fact using the windoes message queue for
synchronization .

Best regards,
David Yuan
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.