That assumes that the two threads are sharing a lot of changing context
data. If that were true, no other method will be more efficient than
multithreading. Shared memory, for example, will be no more efficient.
> It also means that other processes suffer,
> because your one multi-threaded process (in the case of 2-way SMP)
> would get twice as many context switches (each thread would need to
> get swapped in and out seperately per processor),
If you care about performance, you shouldn't care about this.
High-performance news servers don't worry about starving a web serving
program. High-performance name servers don't worry about starving a mail
program. Again, the alternative (multiple processes) would cause the same
problem.
> and introduces lots
> of luvverly atomicity nasties, because process data (visible to all
> threads) needs to be available to all processors. Summary: Ouch.
Not so either. Caches handle shared unchanging data just fine.
Overall -- Nonesense. If you're considering multiple threads or multiple
processors, multiple threads are a win all around.
1) You might have fewer context switches. A thread that can keep picking up
whatever work happens to need to be done can run longer than a process that
can only do work for a single connection/job.
2) You might have less expensive context switches. Thread context switches
will require less work since the vm won't change.
3) You might be more responsive. In a multiprocess solution, an ambushed
process will freeze whatever work was assigned to that connection. In a
multithreaded solution, it will only stall the job that thread was doing --
other jobs can then be taken over by other threads.
There are several other factors that weigh in favor or threads, but these
are probably the three biggest.
DS
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/