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 > > (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
