Thread performance (was Re: dynamic context transitions)
David Collier-Brown
davec-b at rogers.com
Sat Dec 4 14:21:34 GMT 2004
On Wed, Dec 01, 2004 at 05:12:24PM -0600, Christopher R. Hertel wrote:
>>I've been asking about this in different places. I've heard theories,
>> mostly. This is happening in Linux (dunno if it's been tested elsewhere)
>> and one theory is that the forked process speeds are good because Linux
>> basically does a really good job with those. Meanwhile, thread speed is
>> bad because the multiple threads are all within a single process and the
>> single process gets only it's own share of processor time.
That was the case with Solaris 7: it was changed to
one kernel thread per user thread in 8, vaguely similar
to the Linux one process-equivalent per thread.
Russell Coker <russell at coker.com.au> wrote:
| Probably threads are best restricted to languages such as Java and Ada
Threads aren't even second-class objects in C: as a result
they're surprisingly hard to debug and maintain. (Languages
where "classes and monitors" are first-class objects have far
less difficulty dealing with them.)
From Tridge's comment, it appears then Linux libc2 tries to make
threads behave like first-class objects, with locking around
thread-unsafe interfaces, for a gain is correctness and a loss in speed.
The Solaris model is to assume programs are unthreaded, and
make it the programmer's responsibility to chose the thread-safe
and high-threaded-performance interfaces, and no others. There
are no locks or warnings about using a thread-unsafe libc function,
it just fails at runtime.
Expect a threaded program that runs correctly in Linux to fail
randomly and mysteriously in Solaris, HP/UX and the like...
This makes it startlingly hard to do portable threaded programs (:-))
--dave (engaging in positively British understatement) c-b
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb at spamcop.net | -- Mark Twain
More information about the samba-technical
mailing list