Messages in this thread | | | Date | Tue, 22 Jul 1997 23:20:47 -0700 (PDT) | From | Alex Belits <> | Subject | Re: ... 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
| |