Any Threading Gurus out there?

[walterd]

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]]

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

 

[William Stacey [MVP]]

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.

 

[wdewebserver]

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

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

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

 

[William Stacey [MVP]]

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

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

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

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

 

[Michael E. Pouliot]

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

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

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

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

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

 

[Jon Skeet [C# MVP]]

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!)

 

[Alvin Bruney [MVP]]

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]]

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.)

 

[Alvin Bruney [MVP]]

(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

 

[Guest]

Hi

You can check whther the thread is running by IsAlive method of the thread
class. You can suspend a thread externally by Suspend method or have a thread
check a boolean value periodically and if that value is true the thread can
go to sleep. Abort is obviously can be done by the Abort method but is not a
recommended way of terminating a thread because it causes an exception.