reuse of threads (urgent)

[Jon Skeet [C# MVP]]

I was thinking that when a thread is made it executes a certain coroutine
and remains executing the same coroutine until the coroutine is finished.
After that the thread inserts itself into a list of free threads. Next time
a coroutine objekt wants to be executed it uses a thread from among the
free/available threads on the list. If there were no free threads then it
should make a new thread. This way I'll keep the number of threads made to
the minimum reducing the memory usage and improve performance.

And that sounds like a typical threadpool, as I described before, just
with the extra proviso of immediately creating a new thread if one
isn't available.

 

[Kovan Akrei]

And that sounds like a typical threadpool, as I described before, just
with the extra proviso of immediately creating a new thread if one
isn't available.

Yes right som how, but there is a fundemental differnce between those
threads I use to implement coroutines and threadpool threads. Threads in a
thread pool are great for doing some small jobs that terminates. In my case
the job that a thread has to do might be long and extensive. Threads might
(in many cases forced to) give up control to other threads and later have to
continue doing the job, give the control again and so on. There might be
hundreds of threads doing this.
I use threads to implement coroutines (explained in a previous post).When a
thread that is executing a coroutine A my have to be suspend for a while due
to a a call from this coroutine (coroutine A) to give up the control in
favour of another coroutine B. Coroutine B does some work and give the
controll to a coroutine C and so on. Some where in this ocean of threads a
coroutine X may then give the contol back to A. Then A should continue from
its activation point and continue its work. After that and long before its
finished with its task hase to give up control again in favour of another
coroutine R.
This means that every thread which is executing a coroutine should presserve
its execution state. By doing so its alive and "knows" where to continue
when it get the control back.
Let say that I have a simulation system that contains more than 25
coroutines (uses more that 25 threads) and we are using ThreadPool. The task
every coroutine does is very long and takes more than 5 minutes. Let say
that each coroutine does some work and before its finished it gives the
control to the next coroutine. All the first 25 coroutines does this without
a problem. All the 25 threads which are asosiated coroutines are a live.
What happens when coroutine number 25 wants to start/resume the execution of
coroutine number 26? In my openion the simulation system will stop.

Kovan

 

[Jon Skeet [C# MVP]]

Let say that I have a simulation system that contains more than 25
coroutines (uses more that 25 threads) and we are using ThreadPool.

I wasn't suggesting using the standard threadpool - I was suggesting
writing your own. However, you should still be aware that if you create
hundreds of threads, even if most of them are sleeping, you may run
into resource problems.

 

[William Stacey]

I don't think a Cray could handle that either...

 

[William Stacey]

This sounds a little like a GOF State Pattern could be used here. Have a
controlling Class "Master" that has a private member called coRoutine of
Type CoRoutine. Create your CoRoutine class as an abstract class. Derive
coroutines from CoRoutine base class. Each derived type will have a "Run()"
method (for example.) So you have (as example) derived classes coRoutineA
and coRoutineB. Inside the "Run" method, you decide what coRoutine to run
next which changed the "state" object in the container class to what ever
coRoutine you need to run next.

 

[Dave]

you normally get about 800 to 900 per 1gb machine.


Thats the experience I had, so if you get millions, how much ram do you
have??? the mind boggles.

I want one of those machines for Christmas...I'll load every book ever
written, every song ever sung, all into memory at the same time....

 

[Dave]

I ment in theory.

Not all of them are active at the same time. May be I was not that clear in
my original posting. I didn't mean that you should run millions of threads.
I ment that the system (my system) could generate millions of threads where
many (thousends??) of them could be active at the same time

It still doesn't matter. Whether they are what you call active or inactive
(I presume this means blocked/suspended versus executing) is irrelevant; the
most you can have in existence at any single time will be limited by the
amount of virtual address space available to your application. If your
design calls for this many threads to exist simultaneously, regardless of
its execution state, then I would revisit the design.

BTW, the absolutely most efficient design is one where there is a single
thread per processor in the ready to run queue - any more then that and you
start to lose efficiency due to the overhead of context switching. In
practice more then one is fine, but thousands that are all ready to run will
bog the machine down to a crawl.

It sounds like a custom thread pool will solve your problem. I know of
several that are freely available which you should be able to modify to suit
your needs.

(read my extra
notes to my original post).

I can't find them; pls repost them if they are relevant.

 

[Kovan Akrei]

It still doesn't matter. Whether they are what you call active or inactive

(I presume this means blocked/suspended versus executing) is irrelevant; the
most you can have in existence at any single time will be limited by the
amount of virtual address space available to your application. If your
design calls for this many threads to exist simultaneously, regardless of
its execution state, then I would revisit the design.

That is what Im trying to do by economizing on thread usage . I'm aware of
the performance and memory problems. One should not think (due to my
simulation issue) of system (pv or os) boundries. Think in a general way
where you have enough memory and your os handles more that X number of
threads.

BTW, the absolutely most efficient design is one where there is a single
thread per processor in the ready to run queue - any more then that and you
start to lose efficiency due to the overhead of context switching. In
practice more then one is fine, but thousands that are all ready to run will
bog the machine down to a crawl.

That's right. We are talking about simulations and in a simulation you will
probably have many many processes (threads).

It sounds like a custom thread pool will solve your problem. I know of
several that are freely available which you should be able to modify to suit
your needs.

May be. I was thinking of programing one by myself. That's why i start all
this by postin the original note. I was not that clear in that post .
If you know of some custom threadpools would you please share it with me and
other users?

I can't find them; pls repost them if they are relevant.

I sent the extra notes as a reply to my original post. You will find there.

Kovan

 

[Dave]

If you know of some custom threadpools would you please share it with me and
other users?

Here's one:
http://staff.develop.com/woodring/dotnet/#threadpool

 

[Kovan Akrei]

thanks. I'll ut out very soon .

Here's one:
http://staff.develop.com/woodring/dotnet/#threadpool

 

[Mike Blake-Knox]

Coroutines don't require threads (and were actually invented in the
1950s. There's a nice little history in Vol 1 of Knuth's Art of
Computer Programming.)

If context switching in Operating System level threads is a concern,
you can use an approach similar to how Posix threads were originally
implemented on many Unix based operating systems (and in early versions
of the Java VM?). As it sounds like you probably don't need a
preemptive multitasking environment, this sort of approach would seem
to minimize operating system overhead.

It might even extend to "millions" of (non OS) threads.

Mike Blake-Knox

 

[Willy Denoyette [MVP]]

Jon Dave,

FYI. A number of these issues will be addressed in V2.0.

Willy.

PS. Jon, Congrats on the MVP status, well deserved.

 

[Willy Denoyette [MVP]]

Kovan,
You could do as Jon suggest, write your own threadpool, but if you need that very high number of threads you should definitely
implement it using a combination of threads and fibers, otherwise you will run into CPU and memory resource problems.

Willy.

 

[Kovan Akrei]

Hi Willy,
I would like to try out fibers, but I do not know (yet) what they are. I
have implemented my package using threads and it works ome how nice but I
would realy like to exepriment more nad fibers sound something new for me
.

Kovan

Kovan,
You could do as Jon suggest, write your own threadpool, but if you need

that very high number of threads you should definitely

implement it using a combination of threads and fibers, otherwise you will

run into CPU and memory resource problems.

Willy.

 

[Willy Denoyette [MVP]]

Read following article and the MSDN SDK documentation, but be warned, fibers are not that general purpose and are a lot more
complicated to use than regular kernel threads, you should to stay away from it, if you can
http://msdn.microsoft.com/msdnmag/issues/03/09/CoroutinesinNET/default.aspx

Willy.

Hi Willy,
I would like to try out fibers, but I do not know (yet) what they are. I
have implemented my package using threads and it works ome how nice but I
would realy like to exepriment more nad fibers sound something new for me
.

Kovan

Kovan,
You could do as Jon suggest, write your own threadpool, but if you need

that very high number of threads you should definitely

implement it using a combination of threads and fibers, otherwise you will

run into CPU and memory resource problems.