lkml.org 
[lkml]   [1997]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: ... a comment on threads....
On Tue, 22 Jul 1997, Teunis Peters wrote:

> > (Insert standard claim about why I think threads are a bad idea for most
> > application programs; there are plenty of kernel programmers have a hard
> > time writing thread-safe kernel code --- and we expect *application*
> > programmers to be able to get this stuff right? It's like handing a
> > loaded .45 to a chimpanzee and hoping he won't shoot himself or others
> > while he's playing with it. :-)
> >
> > (Yes, I know sometimes you need threads for performance reasons; but you
> > better have someone who really knows what they are doing, and the times
> > when you need threads are much rarer than you think.)
>
> 100% of time with realtime or Java-style coding.
> A real performance boost to X [if done properly].
> though if someone NEEDS threads [other than Java], they play with fire!

Java is designed for three systems:

1. Windows (95, NT).
2. Solaris.
3. Still unknown non-multitasking one-chip implementation.

They are known by somehow slow process context switching, lack
of native unixlike IPC (Windows) or STREAMS-based implementation of it
(Solaris) that was compensated by fast threads context switch.

I never seen any evidence that Sun intended it to be used anywhere else.
Sure, beats Visual Basic, but that's it.

> [speaking of one who LIKES playing with fire :]
>
> You don't solve this by preventing application programmers from coding
> threads.... you solve this by having thread-safe libraries or by making
> thread creation/control very esoteric :)

...and possibly creating nasty overhead for everyone not interested in
threads thus causing them to actually use threads for performance that was
lost by "threadifying" every existing library.

I have seen _ONE_ valid example of threads being definitely more
efficient in Linux compared to classical nonblocking I/O, (pagefault on
serving file descriptor just received from select()), and it's still not
that severe in situation where the same pagefault causes blocked process
to continue I/O as opposed to other threads, and such situation isn't so
common in high-loaded servers that don't have most of memory used in
select() loop swapped out anyway. Cache flushing while being a valid
reason for threads in extremely-fast-context-switching application,
doesn't gain much otherwise, and overhead of syncronization can eat
everything, so "processes are less efficient than threads" statement needs
a lot of if's to be added to be true for Linux userland applications/libraries.

--
Alex


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.053 / U:1.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site