a) asynchronous IO - what you really want is *asynchronous IO*, not
threads emulating asynchronous IO. The thread overhead is unnecessary
expensive for AIO (thread creation/destruction, thread stack allocation,
etc.).
b) using SMP features within a parallelized app - yes, threads are a
good idea here.
c) parallel programming languages such as VHDL, which support parallel
execution blocks. It turns out that the locking overhead of using real
threads (especially on SMP) is much higher than the gain - use a
cooperative user-level approach instead. These blocks do very little
work (e.g. assign a variable with a simple statement), and often all
active blocks fit into the cache, avoiding the context switch refill
Larry mentioned. Since there is no/little local state on the stack or in
registers to preserve when switching from one block to the other, the
user-level approach is much much faster. I've compared a Solaris thread
implementation of such a hardware simulation with a complete user-level
approach, and the latter was 3 to 5 times faster *overall* (including
the actual simulation work).
-- Bernd Paysan
- 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/