Thread A notifying Thread B of an Event

"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).

You can use addhandler... If you remember from your thread creation you
have something like

Dim ThreadA as new System.Threadin g.thread(Addres sOf myClass.MyFunct ionA)
Dim ThreadB as new System.Threadin g.Thread(Addres sOf myClass.MyFunct ionB)

now these act like any other class... Which means you can raisevents and
hook between threads (a lot of us design this way, how do you think we make
data intensive UI's so damn quick.=))

So, all those events in A are availible in B through your class
declaration... say classA has eventA and classB has eventB...

So.. lets try this.

sub main()

dim classA as new myClassA
dim classB as new myClassB

AddHandler classA.eventA, New EventHandler(Ad dressOf classB.onEventA )
...thread starting...

end sub

ClassB.onEventA is a matching eventhandler to the class A event (I just
used an argumentless event handler delegate (thats what EventHandler is...)

Delegates ensure communication across threads... (one of there many useful
purposes)

And thats about it...

HTH,
CJ
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

Thanks for your help, but I am afraid I am going to need far more
explaination. I have played with your comments for some time now, and
cannot get them to work in any meaningful way.

I have no problem with Raising an event that is caught higher up in the call
stack. But raising an event in one thread caught by a 2nd thread handler
simply isn't working as expected.

Question: If thead A raises an event caught by thread B, I would expect the
delgate to be running on thread B . But debug inidcates that thread A is
running the delagate on thread B. Is this correct? This will present a
host of problems.

Can you reference a URL or more detailed areticles on this issue? I have
searched MSDN, and have not come up with sample code or a good explaination.
Any type of sample code the works would be appreciated.

Thanks!

Bob
"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 Bob,

A queue is the preferred way to send data across free-thread boundaries.
There is an online chat that has discussion of this on:
http://msdn.microsoft.com/chats/vstu...dio_041602.asp

Alan Dennis book, .NET Multithreading does quite a good job of explaining
this, and provides example code. You can get information from the publisher
at www.manning.com -- the books is available in both print and eBook
versions.

Dick
--
Richard Grier (Microsoft Visual Basic MVP)

See www.hardandsoftware.net for contact information.

Author of Visual Basic Programmer's Guide to Serial Communications, 3rd
Edition ISBN 1-890422-27-4 (391 pages) published February 2002.

Hi Bob,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
From your description, I understand that you have two threads, and you hope
thread A will tell thread B that something has been done.
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Based on my experience, if the event handler is on thread A, it will be
fired on Thread A and will not on thread B. To achieve your aim, the Timer
will be a good solution, also you may try to use the .net framework buildin
synchronized object.
e.g. Mutex.
You can wait for the Mutex in Thread B, and after the Thread A has done
something, thread A will realease the mutex and then thread B which is
waiting for the object return and the Thread B will run continuely.

Synchronizing Data for Multithreading
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconmanagedthr eadingsupport.a sp

Mutex
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconmutex.asp
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Based on my experience, if the event handler is on thread A, it will be
fired on Thread A and will not on thread B. To achieve your aim, the Timer
will be a good solution,
A Timer? How on earth did you get a job at MS Peter? I swear your
"solutions" are the most ill thought out ideas on the planet. Again, you
have completly missed the point on this dicussion and have offered nothing
valuable to add to it.
also you may try to use the .net framework buildin
synchronized object.
e.g. Mutex.
I don't believe synchronization was what he was asking....
You can wait for the Mutex in Thread B, and after the Thread A has done
something, thread A will realease the mutex and then thread B which is
waiting for the object return and the Thread B will run continuely.

Synchronizing Data for Multithreading
http://msdn.microsoft.com/library/de...us/cpguide/htm l/cpconmanagedthr eadingsupport.a sp

Mutex
http://msdn.microsoft.com/library/de...us/cpguide/htm l/cpconmutex.asp
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

Hi CJ,

I have read it 10 times (the problem) I did that because it is for Peter
difficult to defend himself. I think that a timer is in this case one of the
solutions (and in my eyes even the best).

The main difficult is the problem description, in my opinion it starts with
bringing us probably on the wrong leg. It is telling about a common
datasource, probably meant with that the database while we are using the
word common datasource for something else (not that it is used wrong, but
just because we are using it mostly in another meaning)...

Than it is for the rest one solution which uses in every thread its own
datatables completely separated as well in the database as in the datasets
(it are 2 lines, but if it where hundred it was the same in my idea)

Then there is a horizontal event necessary, and that is weird, in this
situation, there is no need for line 1 to see activity on line 2 and visa
versa (think that it would be 100lines).

The main program can be used to keep track on the activities time by time by
information given to it from the threads. (Not told that it should, this is
just guessing).

For that is a timer very good usable in my idea.

And I do not think that Peter's sollution are that bad, he is given them
mostly on not answered threads and therefore he has probably to guess a lot.

Cor

Cor,

Hi CJ,

I have read it 10 times (the problem) I did that because it is for Peter
difficult to defend himself. I think that a timer is in this case one of the solutions (and in my eyes even the best).

Timers just seem to be wasted time on the CPU. Not the time they take to
iterate (because I know they sleep their thread until its time to raise the
tick). But to constnatly parse through your data tables to notice if there
is a change seems HIGHLY inefficient.

As for horizontal events, I don't see this as being a big problem. Now,
maybe I didn't explain myself well enough, I don't know. But look at it
this way.

In order to work horizontally, ThreadA needs to know the existance of
ThreadB and ThreadB needs to know the existance of threadA. So you can do
this with simple object references. Obviously, some thread has to start
both A and B (they just can't start out of no where) so that can place a
property in A and a property in B to be references back to the opposite
class that is running the method on a separate thread.

Now, since we have both references within the object (even though they are
running on different threads) we can still hook the events to that
particular instance, then use a delegate to bring it over the thread boundry
to update the dataset on the opposing thread.

So, what are we supposed to hook? Well, internally in each class you could
tell it to hook the rowchanged/rowchanging event on a datatable, then define
your own event to hook between the threads (to send additional data if so
desired).

Then on the actual methods that process the changes, do whatever you want
within that separated thread.

Now, does this work on 100 lines? Sorta, it requires a little more work to
make it work properly, but that wasn't the question at hand now was it.
Same concept though, except you could use the main thread to do the
delegating...

But a timer? come on Cor...

The main difficult is the problem description, in my opinion it starts with bringing us probably on the wrong leg. It is telling about a common
datasource, probably meant with that the database while we are using the
word common datasource for something else (not that it is used wrong, but
just because we are using it mostly in another meaning)...

Than it is for the rest one solution which uses in every thread its own
datatables completely separated as well in the database as in the datasets
(it are 2 lines, but if it where hundred it was the same in my idea)

Then there is a horizontal event necessary, and that is weird, in this
situation, there is no need for line 1 to see activity on line 2 and visa
versa (think that it would be 100lines).

The main program can be used to keep track on the activities time by time by information given to it from the threads. (Not told that it should, this is just guessing).

For that is a timer very good usable in my idea.

And I do not think that Peter's sollution are that bad, he is given them
mostly on not answered threads and therefore he has probably to guess a lot.
Guesses a lot? I'm going to use that one next time a company asks me why
something doesn't work. I'm just going to say "Yeah, I guessed on how it
should work... sorry it cost you so much money... but such is life."
Cor

Hi CJ,

I think it is not an horizontaly approach and that is the problem.
I think the current solution should be seen as something like this.

Sub main
- thread B (which uses a timer to control)
- thread A.

While it should be in my opinion
Sub main (Which uses a system.threadin g.timer to do checking time by time,
or a better method if it is needed that if it has to be in real time)
- thread A
- thread B
- thread Xn.

Than could all the threads be from the same class.

But as I said, the problem is not really clear for me.

But again just my thought.

And what about Peter, your message did look to me a little bit if he did
everything wrong.
But I think that makes mistakes like you and me ("lessons") but not that
much as I got the idea from your message.

:-))

Cor

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