How can I handle threading in a scenario like the following? The tasks have
to execute simultaneously. I need a way of identifying which thread is busy
running and its status and also be able to abort or cause one thread to
sleep.

foreach(DataRow row in TaskTable.Rows)
{
CompData compData = new CompData(row["TASK_ID"].ToString(),
row["TASK_PERC"]);
Thread taskThread = new Thread(new ThreadStart(compData.PerformTask));
taskThread.Name = row["TASK_NAME"].ToString();
taskThread.Start();
}

TIA

I'd recommend you use the threadpool.

Otherwise, you will have to store the taskThread reference on a stack
somewhere and then loop the items in this list (after the start()) call
examining the each thread. The reference will allow you access to the
executing thread. You then need to modify your PerformTask routine to
examine global/static flags so that you can cause them to go to sleep etc.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
----------------------------------------------------------


"walterd" <(E-Mail Removed)> wrote in message
news:%(E-Mail Removed)...
> How can I handle threading in a scenario like the following? The tasks
> have
> to execute simultaneously. I need a way of identifying which thread is
> busy
> running and its status and also be able to abort or cause one thread to
> sleep.
>
> foreach(DataRow row in TaskTable.Rows)
> {
> CompData compData = new CompData(row["TASK_ID"].ToString(),
> row["TASK_PERC"]);
> Thread taskThread = new Thread(new ThreadStart(compData.PerformTask));
> taskThread.Name = row["TASK_NAME"].ToString();
> taskThread.Start();
> }
>
> TIA
>
>

Naturally, thread does != speed. So it very well could be that one thread
for each row will cause the entire job to complete much *slower then if just
using one thread or a thread pool. If you do need threads, I would also use
the Thread pool like Alvin said unless you have a compelling reason not to.
Would need to know more about the requirements.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"walterd" <(E-Mail Removed)> wrote in message
news:#(E-Mail Removed)...
> How can I handle threading in a scenario like the following? The tasks
have
> to execute simultaneously. I need a way of identifying which thread is
busy
> running and its status and also be able to abort or cause one thread to
> sleep.
>
> foreach(DataRow row in TaskTable.Rows)
> {
> CompData compData = new CompData(row["TASK_ID"].ToString(),
> row["TASK_PERC"]);
> Thread taskThread = new Thread(new ThreadStart(compData.PerformTask));
> taskThread.Name = row["TASK_NAME"].ToString();
> taskThread.Start();
> }
>
> TIA
>
>

Thank you both for your prompt response. The tasks are all rather long
running processes and I need a way were they can run in parallel. If I use
just one thread, I end up having a long batch window. As you suggest using a
ThreadPool, do you have any examples that I can use? I need to show the
status of the thread as well.

TIA


"William Stacey [MVP]" <(E-Mail Removed)> wrote in message
news:etu%(E-Mail Removed)...
> Naturally, thread does != speed. So it very well could be that one thread
> for each row will cause the entire job to complete much *slower then if
just
> using one thread or a thread pool. If you do need threads, I would also
use
> the Thread pool like Alvin said unless you have a compelling reason not
to.
> Would need to know more about the requirements.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
> "walterd" <(E-Mail Removed)> wrote in message
> news:#(E-Mail Removed)...
> > How can I handle threading in a scenario like the following? The tasks
> have
> > to execute simultaneously. I need a way of identifying which thread is
> busy
> > running and its status and also be able to abort or cause one thread to
> > sleep.
> >
> > foreach(DataRow row in TaskTable.Rows)
> > {
> > CompData compData = new CompData(row["TASK_ID"].ToString(),
> > row["TASK_PERC"]);
> > Thread taskThread = new Thread(new
ThreadStart(compData.PerformTask));
> > taskThread.Name = row["TASK_NAME"].ToString();
> > taskThread.Start();
> > }
> >
> > TIA
> >
> >
>

In that case, spining up a new thread for each one is probably the way to go
as long as not over 800 or so. I would contain the thread inside an
object - say MyWorker. MyWorker will have things like Start()/Stop()
methods and any properties you want to monitor. Then just store MyWorkers
in an arraylist or something. Then you can easily enum the arraylist to see
what each thread is doing, report status, etc. MyWorker would need to sync
any shared vars as normal as your vars will be updated by the worker thread
and read by some other thread(s) such as monitors, etc.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"wdewebserver" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Thank you both for your prompt response. The tasks are all rather long
> running processes and I need a way were they can run in parallel. If I use
> just one thread, I end up having a long batch window. As you suggest using
a
> ThreadPool, do you have any examples that I can use? I need to show the
> status of the thread as well.
>
> TIA
>
>
> "William Stacey [MVP]" <(E-Mail Removed)> wrote in message
> news:etu%(E-Mail Removed)...
> > Naturally, thread does != speed. So it very well could be that one
thread
> > for each row will cause the entire job to complete much *slower then if
> just
> > using one thread or a thread pool. If you do need threads, I would also
> use
> > the Thread pool like Alvin said unless you have a compelling reason not
> to.
> > Would need to know more about the requirements.
> >
> > --
> > William Stacey, MVP
> > http://mvp.support.microsoft.com
> >
> > "walterd" <(E-Mail Removed)> wrote in message
> > news:#(E-Mail Removed)...
> > > How can I handle threading in a scenario like the following? The tasks
> > have
> > > to execute simultaneously. I need a way of identifying which thread is
> > busy
> > > running and its status and also be able to abort or cause one thread
to
> > > sleep.
> > >
> > > foreach(DataRow row in TaskTable.Rows)
> > > {
> > > CompData compData = new CompData(row["TASK_ID"].ToString(),
> > > row["TASK_PERC"]);
> > > Thread taskThread = new Thread(new
> ThreadStart(compData.PerformTask));
> > > taskThread.Name = row["TASK_NAME"].ToString();
> > > taskThread.Start();
> > > }
> > >
> > > TIA
> > >
> > >
> >
>
>

That still depends on the work being done by each thread. If the work was
locally CPU intensive, then 800 threads would cause an enormous amount of
CPU thrashing via context switching. If the work was network oriented (such
as being primarily remote DB calls to SQL Server), then a "thread per job"
approach isn't as big of an issue.

MP

"William Stacey [MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> In that case, spining up a new thread for each one is probably the way to
go
> as long as not over 800 or so. I would contain the thread inside an
> object - say MyWorker. MyWorker will have things like Start()/Stop()
> methods and any properties you want to monitor. Then just store MyWorkers
> in an arraylist or something. Then you can easily enum the arraylist to
see
> what each thread is doing, report status, etc. MyWorker would need to
sync
> any shared vars as normal as your vars will be updated by the worker
thread
> and read by some other thread(s) such as monitors, etc.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
> "wdewebserver" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Thank you both for your prompt response. The tasks are all rather long
> > running processes and I need a way were they can run in parallel. If I
use
> > just one thread, I end up having a long batch window. As you suggest
using
> a
> > ThreadPool, do you have any examples that I can use? I need to show the
> > status of the thread as well.
> >
> > TIA
> >
> >
> > "William Stacey [MVP]" <(E-Mail Removed)> wrote in message
> > news:etu%(E-Mail Removed)...
> > > Naturally, thread does != speed. So it very well could be that one
> thread
> > > for each row will cause the entire job to complete much *slower then
if
> > just
> > > using one thread or a thread pool. If you do need threads, I would
also
> > use
> > > the Thread pool like Alvin said unless you have a compelling reason
not
> > to.
> > > Would need to know more about the requirements.
> > >
> > > --
> > > William Stacey, MVP
> > > http://mvp.support.microsoft.com
> > >
> > > "walterd" <(E-Mail Removed)> wrote in message
> > > news:#(E-Mail Removed)...
> > > > How can I handle threading in a scenario like the following? The
tasks
> > > have
> > > > to execute simultaneously. I need a way of identifying which thread
is
> > > busy
> > > > running and its status and also be able to abort or cause one thread
> to
> > > > sleep.
> > > >
> > > > foreach(DataRow row in TaskTable.Rows)
> > > > {
> > > > CompData compData = new CompData(row["TASK_ID"].ToString(),
> > > > row["TASK_PERC"]);
> > > > Thread taskThread = new Thread(new
> > ThreadStart(compData.PerformTask));
> > > > taskThread.Name = row["TASK_NAME"].ToString();
> > > > taskThread.Start();
> > > > }
> > > >
> > > > TIA
> > > >
> > > >
> > >
> >
> >
>

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
> I'd recommend you use the threadpool.
>
> Otherwise, you will have to store the taskThread reference on a stack
> somewhere and then loop the items in this list (after the start()) call
> examining the each thread. The reference will allow you access to the
> executing thread. You then need to modify your PerformTask routine to
> examine global/static flags so that you can cause them to go to sleep etc.

hile I would agree that using thread pools is a generally good idea,
I'd personally recommend against using the built-in system thread pool,
usually. It's very easy to end up in deadlock situations if your thread
pool tasks use (often without your knowledge) other thread pool threads
- and if you have enough threads waiting for other thread pool threads
to do something, you deadlock.

If you use a custom thread pool which is entirely separate, you can't
run into this problem as easily.

There are plenty of custom thread pool classes around - I have one in
my (free) MiscUtil library at
http://www.pobox.com/~skeet/csharp/miscutil

(I must write more about this problem in my threading article some
time... along with stuff about Thread.Abort etc!)

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> usually. It's very easy to end up in deadlock situations if your thread
> pool tasks use (often without your knowledge) other thread pool threads
> - and if you have enough threads waiting for other thread pool threads
> to do something, you deadlock.
OP didn't indicate that. OP just wants to examine thread states and call
abort. A custom threadpool introduces uneeded complexity without
any added benefit.

--
Regards,
Alvin Bruney [Microsoft MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
----------------------------------------------------------


"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
>> I'd recommend you use the threadpool.
>>
>> Otherwise, you will have to store the taskThread reference on a stack
>> somewhere and then loop the items in this list (after the start()) call
>> examining the each thread. The reference will allow you access to the
>> executing thread. You then need to modify your PerformTask routine to
>> examine global/static flags so that you can cause them to go to sleep
>> etc.
>
> hile I would agree that using thread pools is a generally good idea,
> I'd personally recommend against using the built-in system thread pool,
> usually. It's very easy to end up in deadlock situations if your thread
> pool tasks use (often without your knowledge) other thread pool threads
> - and if you have enough threads waiting for other thread pool threads
> to do something, you deadlock.
>
> If you use a custom thread pool which is entirely separate, you can't
> run into this problem as easily.
>
> There are plenty of custom thread pool classes around - I have one in
> my (free) MiscUtil library at
> http://www.pobox.com/~skeet/csharp/miscutil
>
> (I must write more about this problem in my threading article some
> time... along with stuff about Thread.Abort etc!)
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

<"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
> > usually. It's very easy to end up in deadlock situations if your thread
> > pool tasks use (often without your knowledge) other thread pool threads
> > - and if you have enough threads waiting for other thread pool threads
> > to do something, you deadlock.

> OP didn't indicate that. OP just wants to examine thread states and call
> abort. A custom threadpool introduces uneeded complexity without
> any added benefit.

So were you only suggesting looking at the thread states from a thread
pool thread? I thought you were suggesting doing all the work on thread
pool threads.

(In general, using a custom thread pool hardly adds any complexity over
using the system thread pool though, and reduces how much you need to
worry in terms of other calls using the same thread pool.)

--
Jon Skeet - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

> (In general, using a custom thread pool hardly adds any complexity over
> using the system thread pool though, and reduces how much you need to
> worry in terms of other calls using the same thread pool.)
I don't have much experience with a custom pool, i'll take a look at one
later today
and see if that changes anything

--
Regards,
Alvin Bruney [Microsoft MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ http://www.lulu.com/owc
----------------------------------------------------------


"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> <"Alvin Bruney [MVP]" <vapor at steaming post office>> wrote:
>> > usually. It's very easy to end up in deadlock situations if your thread
>> > pool tasks use (often without your knowledge) other thread pool threads
>> > - and if you have enough threads waiting for other thread pool threads
>> > to do something, you deadlock.
>
>> OP didn't indicate that. OP just wants to examine thread states and call
>> abort. A custom threadpool introduces uneeded complexity without
>> any added benefit.
>
> So were you only suggesting looking at the thread states from a thread
> pool thread? I thought you were suggesting doing all the work on thread
> pool threads.
>
> (In general, using a custom thread pool hardly adds any complexity over
> using the system thread pool though, and reduces how much you need to
> worry in terms of other calls using the same thread pool.)
>
> --
> Jon Skeet - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too