On Thursday 27 September 2001 04:09, you wrote:
> This depends on your system. Solaris has a huge difference between
> thread and process context switch times, whereas Linux has very little
> difference (and in fact a Linux process context switch is about as
> fast as a Solaris thread switch on the same hardware--Solaris is just
> a pig when it comes to process context switching).
I have never worked on any big systems but from what (little) I have seen, I
think there should be a hybrid model.
This whole discussion started off, from poor performance on SMP machines. If
I am getting this correctly, threads can be spread on multiple CPUs if
available but process can not.
So I would suggest to have threaded approach for intensive tasks such as
sorting/searching etc. IMHO converting entire paradigm to thread based is a
huge task and may not be required in all cases.
I think of an approach. Threads are created when they are needed but they
are kept dormant when not needed. So that there is no recreation overhead(if
that's a concern). So at any given point of time, one back end connection has
as many threads as number of CPUs. More than that may not yield much of
performance improvement. Say a big task like sorting is split and given to
different threads so that it can use them all.
It should be easy to switch the threading function and arguments on the fly,
restricting number of threads and there will not be much of thread switching
as each thread handles different parts of task and later the results are
merged.
Number of threads should be equal to or twice that of number of CPUs. I don't
think more than those many threads would yield any performance improvement.
And with this approach we can migrate one functionality at a time to threaded
one, thus avoiding big effort at any given time.
Just a suggestion.
Shridhar
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com