On Thu, 3 Mar 2005 02:06:12 +0000, Eduardo Tongson <[EMAIL PROTECTED]> wrote: > On Thu, 03 Mar 2005 00:47:58 +0800, Andy Sy <[EMAIL PROTECTED]> wrote: > > > 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. > > > > each kernel context handles any number of threads. > this is more complicated than a 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. > > This is true vs cow procs, you can consult your favorite kernel programmer :) > > > 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? > > > > It depends, threads has is it uses and cow procs isn't best for > everything either > > > 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'? > > > > For example M:1 won't scale > and M:N implementations which are unfinished or broken > > > > > 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. > > Linux is 1:1
Does this apply to the current 2.6 kernel? AFAIK, the current scheduler O(1) provides CPU affinity and is SMP-ready. > > > > (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. > > > > > > Not familiar with NT thanks for the info > > > -- > Eduardo Tongson > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6033AC66 > -- > 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 > -- 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
