http://www.systemlogic.net/articles/01/6/multithreading

Any comments? Thoughts?

__________________
ActiveTuning - Partner & Director Of Sales & Marketing

Good article, gave me some insight as to how multithreading
works.

__________________
Serious Soldier

I do think that the Macintosh has had a multi-processing operating system, since the 9500MPs came out, and after A *LOT* of consideration, I am not sure that I really understand the definition.

I would hope that the definition of a multi-processing OS include, support for more than 2 processors, and have both the ability of manage itself across processorsr, and allow applications to acces those processors.

I do not think that threads are nessesary, as either earlier implimentations of MPOSs didn't have them, and that further progress could be made in the future, that didn't include them.

I will in further posts talk about Macintosh technology, but I aint no Apple Polisher either. ( This post coming from a 900Mhz Athlon )

__________________
Wisdom and Age go hand in hand, but some times Age walks alone.

It instead *facilitates* multiprocessing. If each of your apps is singly-threaded, then the OS can just arbitrate each of those threads to a processor as necessary. By breaking up the code into smaller chunks, the processor (singly or multiple) can more easily perform out-of-order execution and optimization routines to simplify the task at hand. Furthermore, it's an easier way to allocate resources. If you've got one processor that's 20% idle and another thread that would take 30% of its resources, then that processor wouldn't be able to easily handle the thread.

Basically, breaking up code into smaller fragments allows it to be more easily managed. Of course, there is a limit to how much this can be done before the ends no longer justify the means.

__________________
"And knowing is half the battle!"

I agree with this, somewhat...

Multithreading has to do with breaking up a program so it can be run separatly in different threads, but the core has to be run in ONE thread, that is the case of MySQL, SQL server and Oracle... You can run multiple queries in multiple threads, but the core still has to be run in one single thread...

Now, if you compare the Linux version of MySQL or Oracle to to the Win version you will see that the help files (DLL's and such) are also running in the same thread as the core in the Win example, but in the Linux example, the core is run in one thread and the rest of it is run in the threads that have the least load, they can even exchange loads if necessary...

MP will increase performance somewhat in a NT environment, but it will almost double it in a Linux environment, now you know why...

Patrick

__________________
No question is to dumb if you are prepared for a technical answer...

This assumes that help files are accessed as frequently, and use the same numb oer resources, as the rest of the core. Otherwise, the benefit of running them as separate threads will only be as helpful as the percent of the time (and the time it takes to process) that they represent.

Is it realistic for the help files to be accessed as much as the rest of it? I can easily see how it significantly benefits performance to run them as different threads, I'm simply wondering how often it's the case for it to be beneficial to do so.

__________________
paul@pleaseohpleasedontspamme.slcentral.com
A mathematician is a device for turning coffee into theorems -- P. Erdos

The help files are accessed very frequently in a Win system, the core IS important, but in a normal Win program (especially MS programs) the help files are accessed more frequently than the actual core...

What can i say, unix in general is a better choice, even the old MS Unix version Xenix...

The problem is, there still are not enough programs for Linux or any other Unix version, but Linux is catching up...

I think the future will have a lot to do with Linux, Perl, MySQL, PHP and Wine... Hopefully wine will die eventually, i do not like that solution... That is how i see it, i could be wrong, but i don't think so...

Patrick

__________________
No question is to dumb if you are prepared for a technical answer...