Eduardo Tongson wrote:
AS> So M:1 for a 1-cpu machine and M:2 for a 2-cpu machine, AS> right? Hmmm, I wonder what the different implications AS> for CPU load-balancing are between an M:Ncpus approach AS> versus a 1:1 scheduler.
ET> Minus the overhead of context switching in the kernel
That is of course a given for M:Ncpus (or any M:1 scheme) - assuming that M implies userland threads (ala linuxthreads).
This was not what I was referring to, however. By implications, I meant the algorithms needed to decide which of N existing kernel threads to map a new M thread onto. I.E. how different or similar these would be (easier or harder; more or less efficient) compared to the 1:1 scheme.
ET> Threads are still definitely lighter than cow procs and ET> context switching with threads in the same process doesn't ET> do memory juggling.
So is this an assertion that the IT world article claims are inaccurate? That you cannot use Linux's relatively efficient copy-on-write process forking to substitute in situations where threads would be needed in other Unixes?
ET> Threads should scale better too than cow procs if your os ET> has a proper threading mechanism.
What are the criteria that need to be met in order for an OS' threading mechanism to be considered 'proper'?
ET> LOL in that case something wrong with Firebird or in the os it ET> is run because it should be the other way round as implicated ET> with their respective designs
Under NT, if you don't set affinity to a single processor, then your Firebird threads will keep jumping back and forth from one CPU to another.
It is due to the fact that linuxthreads are an M:1 scheme (M:Ncpu too?) that Firebird Superserver on Linux does not display the same problem. OTOH, this also implies that while Firebird Superserver on Linux will not give the problem displayed on NT, it is still also unable to take advantage of multiple CPUs.
(It would be interesting to see if running Firebird on an NPTL-enabled multi-cpu machine will exhibit a similar problem).
Multithreaded support in Firebird 1.x was a probably a bit of a quick hack in order to give decent performance on OSes that have inefficient multi-process support (such as NT).
The Firebird coders are certainly no lightweights, so I don't think this can be laughingly dismissed as a case of incompetent coding on their part.
The fact that threads couldn't be retrofitted seamlessly in a short period of time bolsters the assertion that proper multi-threading is inherently difficult to do and does not necessarily yield advantages in a transparent manner - you have to be doubly careful about how you fashion your data structures ahead of time.
-- reply-to: a n d y @ n e o t i t a n s . c o m -- Philippine Linux Users' Group (PLUG) Mailing List [email protected] (#PLUG @ irc.free.net.ph) Official Website: http://plug.linux.org.ph Searchable Archives: http://marc.free.net.ph . To leave, go to http://lists.q-linux.com/mailman/listinfo/plug . Are you a Linux newbie? To join the newbie list, go to http://lists.q-linux.com/mailman/listinfo/ph-linux-newbie
