I’m trying to get my head around what the issue is.
Apologies if I’m covering stuff people already know but it helps get my head around it.
Referring back to Mike’s thread, delegate events do not allow threads to “listen to each other”. In the example from jasdev when threadA in classA fires the event FiveSecondEvent the subscribed method classB.FiveSecondHandler is executed by threadA. Just because the method is on another object doesn’t cause any switching of threads.
I recommend you print out the thread ID in your Debug statements to see what is happening.
Looking back at the original problem [quote]one thread is responsible for recieving measurments and sending data to external hardware. Then another thread is interested in knowing about some of these measurments,[/quote].
I can think of some ways to do this.
The simplest would be the first class that is collecting the data to fire off a “data received” event asynchronously by starting a new Thread to call the “data received” event. Remember that if the data passed is a reference type you will need some locking as both threads will be using the same copy of the data.
You could share an autoreset event. The data collecting class would “Set” the autoreset event when new data is available. The class that wants the data would consume the data, reset the event then wait on it.
@ NickP - The original posting asked this question:
“I’m wondering if there is anyone who knows if there any problems with having objects running in separate threads having a two way dependency via events being raised in either class.”
My posts were an answer to his question, and in my first post I said that:
“When Class B raises its event, the handler in Class A is executed in the context of Class B’s thread.”
This is how .NET events work. In order to use this mechanism to communicate between threads, typically one would use the event handler in ClassA to set some variable in ClassA, that threadA reads. threadA would never set this variable, and would probably set a lock on it to ensure its value is correct each time it is read.
@ NickP -
The challenge was, how to subscribe an event handler in ClassA to an event fired by the thread in ClassB and vice versa. I didnt know how this could be managed - what does not mean very much since I am a senior only by age, not by programming skills.
The issue was, that a subscriber class needs a reference to the publisher class in order to subscribe to its events. When the instances of ClassA and ClassB are created by a main thread, the instances of ClassA and ClassB do not have references to each other. I think, with the start method of classA : public void Start(ClassB classB) jasdev brought the reference to ClassB in ClassA.
One thing more one should keep in mind is, that in a one core cpu in reality there is only one program thread. The term that code runs in another thread only means that the scope to the accessible variables is switched.
One thing, that I have not entirely understood is what the statement:
[quote]
“When Class B raises its event, the handler in Class A is executed in the context of Class B’s thread.”[/quote]
means in all possible aspects. The word context can be meant concerning the time of the program execution and concerning the variables that are in the scope of the code in the eventhandler.
That means: are all the eventhandlers that are subscribed to an event executed in the dispatcher timeslice of the thread that fired the event?
Has the code in the eventhandler access to the local variables that are declared in the thread that fired the event?
Regards
Roland