Thread Doubt.

[Ram]

Hi,
I have two threads, one parent thread containing UI and a child thread
waiting for some events from the parent thread. Now, I have two issues: 1)
to keep the child thread active till the end of parent thread. 2) Fire event
from the parent thread to child thread.

To keep the child thread active, i tried different means including
while(1){ application.DoEvents()} but seems that it is not working. I am
unable to make it work.

For the event, I am able to fire events from the child to parent using
delegates, But how to fire it from the parent to child?

Thanx
Ram

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi Ram.

Usually what you do is send the event from the worker thread to the UI
thread, not the opposite.
Why are you keeping a worker thread if it;s not working? Can you create the
thread as a response to the event in the UI and then when the worker thread
finish it does inform the UI it's done? That would be a possible solution.

You have two possible solution if you do not want to change your current
solution
1- A busy waiting ( dont remember if this is the correct term ) you do
expect for a variable to obtain a value, the value is set in the UI thread:

while( true )
{
while( Sleep){}
//Do processing
}

then in the UI thread you do Sleep = false to trigger the worker thread.

This is not the best solution, IMO. also remember to include locking code
when changing the shared variable

2- Put the thread to sleep and then later wake it up
// thread code
//Do processing...
Thread.CurrentThread.Suspend();

//In the UI code to resume the thread.
threadInstance.Resume();


Again, I think that you should rework the code for being the worker thread
the one that send the event to the UI ( using Control.Invoke )


Cheers,

 

[John Murray]

Perhaps I am missing something, but why would you have a thread spun up
that has nothing to do. If all the child thread is doing is waiting for
an event from the parent, why not have the parent use a thread from the
thread pool when a new event occurs that it cares about. Another option
would be to use an AsynchDelegate ... which may give you some other
benefits as far as error handling ..etc..

John

 

[Ram]

Ok. The problem goes like this: I have the main window that listens for
events from devices and COM components. The main window spawns childs (since
there are many to listen to) and starts listening. Whenever the main thread
receives events from these thread, the UI has to be updated. Now I want the
UI updation to happen in separate thread rather than in the main thread. So
I thought of having another thread just to paint and update the UI as I do
not want to overload the main thread as it has to listen for events from
other child thread.
I used to work with CWinThread in vc and everything seems to be possible for
me using PostThreadMessage. Here the equivalent of CWinThread is missing.(or
am I missing something ?)
I am new to C# and till now my exp are with vc. I have to try it out with
ThreadPool.

 

[John Murray]

You may want to consider reversing your logic here. Primarily, this is
because you cannot (well, you can, but results are usually not good)
update your UI on any thread other than the one that it was created on.


As a result, your paints have to happen in your UI thread -- although if
the information that you are updating is from an intensive operation,
you might benefit from having using the threadpool to pre-process the
updates.

John

 

[Thomas P. Skinner [MVP]]

I agree with your last few comments. The windows message loop is abstracted
out to a large extent in the FCL. I have not found any really good
documentation of the implementation. I tell my students to never perform any
UI based operations in a worker thread. I even recommend performing an
Invalidate by the UI thread via an Invoke rather than doing it in the worker
thread. The latter seems to work OK but is technically not recommended. Any
computationally intensive operations can be performed by the worker thread,
but the actual painting by the UI thread.

Thomas P. Skinner [MVP]

 

[Willy Denoyette [MVP]]

I have the main window that listens for

events from devices and COM components. The main window spawns childs
(since
there are many to listen to) and starts listening.

Sorry, but I'm not clear on what you mean, here are some of my questions:
Who is actualy listening for the events from COM and other devices, the UI
thread, the spawned threads or both?
What thread(s) did you create your COM object on?
What threadingmodel do these COM objects use?
Did you set the appartment of the spawned thread accordingly?

Willy.

 

[Ram]

Thanx for the responses. As Thomas & John suggested, I could see a point in
that and have modified the UI logic. Coming to Willy questions:
UI thread waits for events from COM components. These are third party
components. I have not set the appartment model for the spawned thread.

Ram