Threading

  • Thread starter Thread starter Danny Carvajal
  • Start date Start date
D

Danny Carvajal

Hello,

I have an application that uses 5 threads. So I simply create the 5
threads. However, I need to be able to create x number of threads at a
time. Not sure how to do this. Any links to examples of this?

Thanks!
Danny
 
Don't understand. You can only start them one after the other. You can't
start them all at the very same time. You could wait on a mutex or event in
each thread, but on a single cpu only one will start at a time. Could you
explain a bit more what your trying to do. Many times, many threads are not
the right answer.
 
Danny,

Just creating x number of threads at a time is a very bad idea. Unless
you absolutely need them, you should probably use the ThreadPool class to
manage the execution of the threads. If you absolutely need all of those
threads, then just create an array of the appropriate length and create new
Thread objects.

Hope this helps.
 
Nicholas Paldino said:
Just creating x number of threads at a time is a very bad idea. Unless
you absolutely need them, you should probably use the ThreadPool class to
manage the execution of the threads. If you absolutely need all of those
threads, then just create an array of the appropriate length and create new
Thread objects.
Click to expand...

Normally yes, but the system wont even burp at 5. You need a lot more
threads, or a lot of creation and destruction of them in high frequency
before you should even consider thread pooling.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Normally yes, but the system wont even burp at 5. You need a lot more
threads, or a lot of creation and destruction of them in high frequency
before you should even consider thread pooling.
Click to expand...

That wasn't a suggestion that a thread pool should be created from scratch -
it was a suggestion to leverage the Framework's ThreadPool class. There is
no reason to deal with the complexities of thread management if you don't
need to. The Framework's ThreadPool class is perfectly suited for working in
almost all general purpose cases - especially if you're using a few threads.
The only cases where you need to explicitly manage threads are when you have
a need for explicit per-thread management, like:
- You need to set affinity
- You require a specific thread priority
- You really do care about the worker thread's lifetime
- You have semantics that push your requirements outside the
general-purpose envelope covered by ThreadPool

In almost all cases that a threading novice encounters, explicit thread
management is pain for no gain.
 
Mickey Williams said:
In almost all cases that a threading novice encounters, explicit thread
management is pain for no gain.
Click to expand...

There isnt anything to manage, create, start, destroy. Unless you have a
bunch of worker threads that are all instances of the same thread class.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
 
Chad,

As Mikey pointed out, the thread pool I recommended was the system one.
Also, there is something to manage. You have to manage the instances of the
Thread class yourself, and also set up some mechanism for notification when
the thread is done (if it is needed).

You are right, at five threads, it should be no problem (given normal
conditions). However, the OP indicated that they wanted to create x number
of threads at a time. I have interpreted x to be anywhere from one to
positive infinity, which can be a very, very large number. If the number
falls somewhere in the lower end of that range, then I think the ThreadPool
is the best solution, and agree with Mikey's remarks about why you would
create specific thread instances.

You also get a perf advantage as well, which can be important when
trying to manage that many threads. The thread pool will save you the time
normally dedicated to the initialization and teardown of the thread, which
is something you can not avoid easily by creating and managing your own
threads.
 
While we're on the subject, I once read that using a thread pool from within
an aspx process (either an aspx page, or a class library class instanced
from an aspx) was bad news because aspx itself uses the system threadpool,
so you would risk starving the page serving system. Is that true?

Nicholas Paldino said:
Chad,

As Mikey pointed out, the thread pool I recommended was the system one.
Also, there is something to manage. You have to manage the instances of the
Thread class yourself, and also set up some mechanism for notification when
the thread is done (if it is needed).

You are right, at five threads, it should be no problem (given normal
conditions). However, the OP indicated that they wanted to create x number
of threads at a time. I have interpreted x to be anywhere from one to
positive infinity, which can be a very, very large number. If the number
falls somewhere in the lower end of that range, then I think the ThreadPool
is the best solution, and agree with Mikey's remarks about why you would
create specific thread instances.

You also get a perf advantage as well, which can be important when
trying to manage that many threads. The thread pool will save you the time
normally dedicated to the initialization and teardown of the thread, which
is something you can not avoid easily by creating and managing your own
threads.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Chad Z. Hower aka Kudzu said:
There isnt anything to manage, create, start, destroy. Unless you have a
bunch of worker threads that are all instances of the same thread class.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
Click to expand...
Click to expand...
 
J.Marsch,

Yes, I believe that this is true (there was an article in MSDN about it,
I believe). In ASP.NET, I believe the performance numbers indicated that
spawning your own threads was the way to go.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

J.Marsch said:
While we're on the subject, I once read that using a thread pool from within
an aspx process (either an aspx page, or a class library class instanced
from an aspx) was bad news because aspx itself uses the system threadpool,
so you would risk starving the page serving system. Is that true?

message news:[email protected]...
Chad,

As Mikey pointed out, the thread pool I recommended was the system one.
Also, there is something to manage. You have to manage the instances of the
Thread class yourself, and also set up some mechanism for notification when
the thread is done (if it is needed).

You are right, at five threads, it should be no problem (given normal
conditions). However, the OP indicated that they wanted to create x number
of threads at a time. I have interpreted x to be anywhere from one to
positive infinity, which can be a very, very large number. If the number
falls somewhere in the lower end of that range, then I think the ThreadPool
is the best solution, and agree with Mikey's remarks about why you would
create specific thread instances.

You also get a perf advantage as well, which can be important when
trying to manage that many threads. The thread pool will save you the time
normally dedicated to the initialization and teardown of the thread, which
is something you can not avoid easily by creating and managing your own
threads.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Chad Z. Hower aka Kudzu said:
"Mickey Williams" <my first name at servergeek.com> wrote in
In almost all cases that a threading novice encounters, explicit thread
management is pain for no gain.

There isnt anything to manage, create, start, destroy. Unless you have a
bunch of worker threads that are all instances of the same thread class.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"


ELKNews - Get your free copy at http://www.atozedsoftware.com
Click to expand...
Click to expand...
Click to expand...
 
Thanks, I just wanted to make sure that I had that one right!


Nicholas Paldino said:
J.Marsch,

Yes, I believe that this is true (there was an article in MSDN about it,
I believe). In ASP.NET, I believe the performance numbers indicated that
spawning your own threads was the way to go.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

J.Marsch said:
While we're on the subject, I once read that using a thread pool from within
an aspx process (either an aspx page, or a class library class instanced
from an aspx) was bad news because aspx itself uses the system threadpool,
so you would risk starving the page serving system. Is that true?

message news:[email protected]...
Chad,

As Mikey pointed out, the thread pool I recommended was the system one.
Also, there is something to manage. You have to manage the instances
Click to expand...
of
the
Thread class yourself, and also set up some mechanism for notification when
the thread is done (if it is needed).

You are right, at five threads, it should be no problem (given normal
conditions). However, the OP indicated that they wanted to create x number
of threads at a time. I have interpreted x to be anywhere from one to
positive infinity, which can be a very, very large number. If the number
falls somewhere in the lower end of that range, then I think the ThreadPool
is the best solution, and agree with Mikey's remarks about why you would
create specific thread instances.

You also get a perf advantage as well, which can be important when
trying to manage that many threads. The thread pool will save you the time
normally dedicated to the initialization and teardown of the thread, which
is something you can not avoid easily by creating and managing your own
threads.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

"Mickey Williams" <my first name at servergeek.com> wrote in
In almost all cases that a threading novice encounters, explicit thread
management is pain for no gain.

There isnt anything to manage, create, start, destroy. Unless you
Click to expand...
Click to expand...
have
a
Click to expand...
Click to expand...
 
Back
Top