Need Input from Threading Guru

[Phillip N Rounds]

I'm cursed by being a linear thinker.

Anyway, I have an application (service) where I can't decide on the
appropriate way to implement threading.

I have a timer which periodically initiates Process A
Process A does something, then has to call N instances of Process B, where N
varies from instance to instance of Process A.
Process B then has to call M(n) instances of Process C, for each n < N,
where again the # of instances of Process C varies for each call to process
B.

Clearly, I can do the following: ( process A & B are really in seperate
worker classes, but this is a simplified version)

Main Class

OnTimer( )
{
int N = CalculateNumberOfProcessARequirements();
for ( int i = 0; i < N; i++) {
Thread t = new Thread( new ThreadStart( this.ProcessA);
t.Start(); }
return;
}

ProcessA()
{
int M = CalculateNumberOfProcessBRequirements();
for ( int i = 0; i < M; i++) {
Thread t = new Thread( new ThreadStart( This.ProcessB) }
return;
}

ProcessB()
{
DoTheActualWork();
return;
}

My question is, how do I do the book-keeping.

 

[Marcos Stefanakopolus]

My, that's a lot of threads...

Regardless, it's pretty unclear what you mean by "do the bookkeeping".
Assuming you mean "how do I keep track of the data coming back from all
those DoTheActualWork() calls, my inclination would be to:
1. create an event in the Process B class which the class can raise to
indicate that a DoTheActualWork() call has finished, and has some results to
share. Create an EventArgs-derived class to hold the actual results you
want to pass back to the rest of the program.
2. Have an event handler in the main part of the program to process all the
events arising from those DoTheActualWork() calls.

If you need to keep track of which particular instance of DoTheActualWork()
was responsible for a given result, then make sure to give all your threads
unique names when your ProcessA() routine creates them. The individual
this.ProcessB() calls can get their own thread name and include that as part
of their results when they pass results back to the rest of the program via
the EventArgs class. If you're clever about how you name your threads,
you'll be able to determine which thread was which when the results come
back.

If you mean something else by "do the bookkeeping", you'll just have to be
more specific...

 

[Jon Skeet [C# MVP]]

I'm cursed by being a linear thinker.

Anyway, I have an application (service) where I can't decide on the
appropriate way to implement threading.

I think the best way of thinking about how many threads to have is to
think about how many of your processes could *actually* do work in
parallel (rather than just waiting for access to the CPU, for
instance). I'd then think about using a custom thread pool to create
that many threads (possibly one thread pool per process type) and give
the thread pool jobs from the results of the processes.

I have a custom thread pool you could use here:
http://www.pobox.com/~skeet/csharp/miscutil

and an article about threading which you might find helpful here:
http://www.pobox.com/~skeet/csharp/threads

 

[Cor Ligthert]

Phillip,

In additon to the others, think about using queue's.

That will as well need threads however probably you can than do better
book-keeping.

Just my thought,

Cor

 

[Phillip Rounds]

Sorry all, but I hadn't intended to send this question yet.
As most of you noted, I had to further explain the 'Do the bookeeping'
aspect of the question.
I decided to step back before I posted, based on the possiblity that if
I were to fully explain that portion of the post I might actually come
up with a solution myself.
Thanks for the input and, again, sorry for the poorly worded post.

Phil