Sponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
In defense of thousands of threadsIn defense of thousands of threadsPosted Aug 15, 2002 16:13 UTC (Thu) by bhurt (guest, #3281)In reply to: Making Linux safe for pthreads by IkeTo Parent article: Making Linux safe for pthreads The problem with user-space threads is that when one thread blocks, for whatever reason, all threads block. For library calls (read, write, etc) this can be worked around with some difficulty (does Linux support asynchronous I/O yet?). For page faults, the only work around is to spawn more threads than CPUs- that way, when one thread blocks due to a page fault another thread can run. If you assume a couple dozen CPUs, each needing a couple dozen threads to make sure there is always at least one thread that is runnable, you get into thousands of threads really quickly. Brian
(Log in to post comments)
In defense of thousands of threads Posted Aug 19, 2002 11:21 UTC (Mon) by shane (subscriber, #3335) [Link] IBM is currently working on the Next-Generation POSIX Threads effort, which seems to combine the best of both worlds. It creates multiple kernel threads (by default based on the number of CPU's), but not one per user thread. In this way, the kernel doesn't waste time multitasking thousands of kernel threads, but not all threads block if one is busy hogging the context in a computation loop, for instance.Check out the home page: http://www-124.ibm.com/pthreads/ BTW, it's based on GNU Pth.
|
|||||||||||