The Usenet newsgroup comp.programming.threads is a great resource.
Russ Allberry describes thread programming as doing the memory protection, signal-handling, and (some) process management that the OS otherwise does for you. As usual, customization is expensive and dangerous, and often highly satisfying when it works.
Fundamentals Of Multithreading
[Explain how since Java has only blocking I/O, Java workers expect threads ...]
Booker Bense opines that "Native threads in C can be a big win, in perl to date they are a fun toy to play and learn with." Tom Christiansen rather flamboyantly summarizes that "The only difference is that with LWP, memory access is dangerous, and with standard processes, it isn't." I do agree with Tom that we're poor as a profession at debugging threading. I know I am more comfortable with the (relative) provability of processes, co-routines, or continuations.
Dan Sugalski has written an excellent tutorial on Perl threads. Also recommended: the Thread.pm documentation [establish hyperlink], Michael Schilli's introduction to multithreading, and Tom Christiansen's summary. Sugalski also reports his timing experiments with 5.005-5.006.
In early summer 2000, Perl threading remains a hard problem. There's a lot of hair and slowdown. perl.porters-gw covers this most extensively.
Even with Tcl 8.1, only a single thread can access any particular interp; interp trees are "per thread". Most succinctly, Tcl threads communicate only through (Tcl) events.
[Tk not thread-safe--but then, what GUI is, or should be? Swing isn't ...]
Cameron
Laird's personal notes on thread
programming/claird@phaseit.net