On Mon, 2005-07-25 at 09:48 -0500, Jay Sprenkle wrote: > The theory has been proposed that threads aren't better than separate > processes, or application implemented context switching. Does anyone > have an experiment that will prove the point either way? It will have > to be OS specific though, since I'm sure not all thread > implementations are equal.
Define "better". It's evident that many bugs are more common, and some kinds of bugs only appear in threading applications. It's also debatable which is easier to program. I think the only useful measure might be context-switch performance. But note that if two processes (A and B) are doing rapid context switches between eachother, if their pages are all COW the page tables don't need to be updated. Your overhead would at most be comparison time. This behavior occurs quite frequently on unix systems. The question one postulates at this point is comparing page pointers more expensive than locks/system calls. The answer seems to be "usually not" although I have indeed run into cases where the answer is "yes". On other systems, where we have _three_ processes; two that COW their page tables and a third that has it's own address space, rapid context switches between all three if the third process goes between each of the other two (A->c->B->c->A->etc) - such as it is under Windows NT kernels that move many operations like network I/O onto a separate "process" - complete with its own address space and etc. On those systems, locks are definitely cheaper. However: Note that even on those systems, scheduling tasks like that are generally better optimized by moving both A and B's tasks into a single event-driven loop (and let c use the other processor). As a side note, many unix applications can be developed for a single event-driven loop and then with a few well placed fork()s be able to take advantage of multiprocessor systems immediately. If you take memory from your stack- you could even use pthread_create(). In this situation, however, I'd like to point out that we're not using a thread-programming-think even if the underlying technology might be called a thread.
