Is there a way ?

  • Thread starter Thread starter JAM
  • Start date Start date
J

JAM

Is there a way to trigger event such that the event is triggered in
one thread and the event delegate is executed by another ?

I'm guessing here, but I think that when thread triggers the event it
is also the same thread that executes the delegate attached to the
event. Am I right here ?

If the above is true, then id does not works fo me. What I need is
more or less described below.

Let's say that my main ThreadA creates a class, which has an event and
couple of methods and a delegate method to handle some action, that
the Thread A attaches to the event in the class constructor. Once its
all done, initialized etc., ThreadA then creates bunch of children
threads: ThreadB, ThreadC, ThreadD etc, to run some methods of the
class in parallel. My program need ThreadB, C, D etc to signal some
events back to the ThreadA such that the ThreadA executes then some
action. It must be a ThreadA because it involves managing all other
threads, interface, etc. But of course I don't want ThreadA wasting
cycles and waiting in the loop constantly monitoring if its children
threads reached particular point in it's execution. My ThreadA is the
main application thread which is servicing user interface so putting
it to sleep or waiting in the loop is not an option. I would prefer
some signal to be send back to ThreadA (like message in the good old
Windows) so it react then to the event by executing delegate.

Is it possible to do it and how roughly to do it ?

JAM
 
By default, that's what happens, yes.




You're not specific enough about what ThreadA is doing or how you're using  
it.  But the usual approach would be, given a ThreadA that's handling GUI,  
to use the Control.Invoke() method on one of the GUI objects (typically  
your main form if the processing isn't specific to some other control) so 
that your code can be executed on ThreadA.

WPF has a similar technique, and there is also the SynchronizationContext 
class, and of course you can write some code to do this sort of thing  
explicitly too depending on what ThreadA is really doing.

Pete- Hide quoted text -

- Show quoted text -
Click to expand...

The question was more in general, not specific to particular program.
Due to the impact of multicore CPU's (soon to be expected 8 cores on
the desktop) I'm thinking about writing programms that actively use
multiple cores. I'm finding that thread to thread communication
in .NET (and C#) is surprisingly on the primitive side, difficult to
implement, nowhere near familiar communication system such as
messaging which events mechanism encapsulates. I envision that for
efficient use of multiple threads in C# programms in the future there
should be a mechanism to allow for signaling or raising event between
different threads such that one thread raises the event but the other
(one designated) is executing delegate attached to the event.

I wasn't sure if such mechanism is not already built in and I just
don't know about it. The literature I have about multithreading in C#
or .net is rather limited.

JAM
 
You can have Thread A wait on the completion of any or all the child threads
by using wait handles, as in:

WaitHandle.WaitAll(handles); //in the parent thread that launched
all the child threads

where

ManualResetEvent[] handles = new ManualResetEvent[threads.Count];
//size is the total number of child threads

You set the array up so that it is initialized in Thread A, each handle
initialized to false. You can pass one handle to each child thread (via a
ParameterizedThreadStart or some other way).

When a child thread is done, it sets its handle via
handle.Set().

Thread A thus blocks on the WaitAll until all child threads have set the
handle you passed to them.

I, too, have a multi-core application that doles out work to worker threads
and then waits for all to complete. That's how I handled it.

By default, that's what happens, yes.




You're not specific enough about what ThreadA is doing or how you're using
it. But the usual approach would be, given a ThreadA that's handling GUI,
to use the Control.Invoke() method on one of the GUI objects (typically
your main form if the processing isn't specific to some other control) so
that your code can be executed on ThreadA.

WPF has a similar technique, and there is also the SynchronizationContext
class, and of course you can write some code to do this sort of thing
explicitly too depending on what ThreadA is really doing.

Pete- Hide quoted text -

- Show quoted text -
Click to expand...

The question was more in general, not specific to particular program.
Due to the impact of multicore CPU's (soon to be expected 8 cores on
the desktop) I'm thinking about writing programms that actively use
multiple cores. I'm finding that thread to thread communication
in .NET (and C#) is surprisingly on the primitive side, difficult to
implement, nowhere near familiar communication system such as
messaging which events mechanism encapsulates. I envision that for
efficient use of multiple threads in C# programms in the future there
should be a mechanism to allow for signaling or raising event between
different threads such that one thread raises the event but the other
(one designated) is executing delegate attached to the event.

I wasn't sure if such mechanism is not already built in and I just
don't know about it. The literature I have about multithreading in C#
or .net is rather limited.

JAM
 
Thread A thus blocks on the WaitAll until all child threads have set the
handle you passed to them.

I, too, have a multi-core application that doles out work to worker threads
and then waits for all to complete.  That's how I handled it.
Click to expand...

I've read briefly about this mechanism, but I didn't like it because
it forced (as far as I understand it) ThreadA to wait. The way I
envisioned my applications was that ThreadA is suppose to be a
supervisor thread, main thread for the application, that services GUI,
thread allocation, tasks allocation, painting etc. In order to be
responsive it must be running, not waiting. For example if user clicks
"STOP" button it suppose immidietly react to it, safely bring all
children threads to some predefined stop state that can be streamed to
the disk for future restoration to continue solving the task later.
But also if child thread will reach some solutions it should signal
this supervisor thread to do some similar or some other action. I can
do it in some twisted way using suspensders and patches, but it
doesn't seem as clean as other C# and .NET constructions. I don't have
a particular program in mind yet. I'm just envisionning how to harness
the power of CPU's that are coming to the market with ease of use that
I like so much in .NET and C#. At this point of time the messaging
mechanism that is used in native Win32 seem to be superior to
everything C# or .NET is offering in that area.

JAM
 
If A were on a separate thread from the UI thread, you can still feed back
results from A (or its worker threads directly) to the UI thread via the
Invoke mechanism mentioned previously. My own experience suggests that to
have A be a separate thread from the UI thread is cleaner/easier to
understand.

If you are using Windows Forms, you could look at BackgroundWorker as a
candidate for thread A. How it does the feedback to the UI is clearly
explained in the MS documentation and other places (Google it). The thread
splitting logic could be added to the worker in the manner I suggested.

In any case, I don't think there is a way for thread X to invoke a method on
thread Y unless Y is the (a) UI thread (and then you can use the Invoke
mechanism).

As you note, A and its worker threads will need to check periodically (and
often) to see if they should shut down. One way is for user input to set a
Bool known to all threads, and serving the basis for quitting (as is done in
the BackgroundWorker mechanism).


Thread A thus blocks on the WaitAll until all child threads have set the
handle you passed to them.

I, too, have a multi-core application that doles out work to worker
threads
and then waits for all to complete. That's how I handled it.
Click to expand...

I've read briefly about this mechanism, but I didn't like it because
it forced (as far as I understand it) ThreadA to wait. The way I
envisioned my applications was that ThreadA is suppose to be a
supervisor thread, main thread for the application, that services GUI,
thread allocation, tasks allocation, painting etc. In order to be
responsive it must be running, not waiting. For example if user clicks
"STOP" button it suppose immidietly react to it, safely bring all
children threads to some predefined stop state that can be streamed to
the disk for future restoration to continue solving the task later.
But also if child thread will reach some solutions it should signal
this supervisor thread to do some similar or some other action. I can
do it in some twisted way using suspensders and patches, but it
doesn't seem as clean as other C# and .NET constructions. I don't have
a particular program in mind yet. I'm just envisionning how to harness
the power of CPU's that are coming to the market with ease of use that
I like so much in .NET and C#. At this point of time the messaging
mechanism that is used in native Win32 seem to be superior to
everything C# or .NET is offering in that area.

JAM
 
Back
Top