> So M:1 for a 1-cpu machine and M:2 for a 2-cpu machine, > right? Hmmm, I wonder what the different implications > for CPU load-balancing are between an M:Ncpus approach > versus a 1:1 scheduler. >
Minus the overhead of context switching in the kernel > > Well, that's exactly the thing, according to the IT World article I > referred to, *Linux processes* are supposedly nearly as efficient as > *Unix threads* (remember, Linux Is Not Unix - it just looks like it > ;-D ) such that one can legitimately substitute multiprocessing > for multithreading in Linux apps and do away with all the headaches > of thread synchronization, etc... ... ... > A copy-on-write fork()-ed process can actually be considered to > be more advanced than threads. With threads, you have to deal with > the headache of protecting memory that _might_ inadvertently be > shared. With copy-on-write, you automatically share memory that > is read-only (no wastage), while memory that gets written to are > automatically replicated such that each process gets its own copy > (no need to worry about synchronization, etc...). > > And of course, when you explicitly need to share the values for > the same variables, you can use shared memory, message passing, > queues, etc... all that fascinating IPC stuff... > > With processes, you are freed from having to deal with most > of the annoying shared-memory housekeeping that you cannot > possibly get away from if you use threads. Threads are still definitely lighter than cow procs and context switching with threads in the same process doesn't do memory juggling Copying pages of memory is IO bound, a tradeoff with cow procs, but I agree they are simpler and cleaner. Threads should scale better too than cow procs if your os has a proper threading mechanism. > > Consider Firebird 1.x, where there is a thread-based Superserver > version and a process-based Classic server. Ironically enough, > the Superserver version (or at least initial versions... not > sure what the situation is now) will not take advantage of SMP and > you have to set its affinity to a single processor if you want to > avoid problems. > > The process-based Classic server, otoh, scales on multiple processors. > LOL in that casesomething wrong with Firebird or in the os it is run because it should be the other way round as implicated with their respective designs :D -- 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
