threads are an operating system feature that provides multiple concurrent flows of control, typically within a process. They have less overhead than a full process, but because all threads in a process share the resources of the process, access to those resources must be carefully synchronized.
A thread shares memory and I/O resources with all other threads in the process, which results in contention for those resources. Threading is "fault-prone, deadlock-prone, priority-inversion-prone". Lock (mis)management makes it poor in scaling. It's hard to reason about thread behavior [justify]. Nevertheless, threads are sometimes useful, and sometimes critical (TODO: elaborate).
Where you may write a program that makes use of threads and seems to be well behaved, it is possible that even on the same platform the behaviour will change over time in a long running thread. The handling of exceptions from threads is, IMHO, broken on all platforms other than Solaris on Sparc. The glibc folks are working overtime to remedy this by fixing thread safety issues, and it is *possible* that things will improve significantly by the end of 2002.
I am not referring to the Tcl threading model, which is (apparently) designed to mitigate the effects of non-reentrant code (I admit to not being up on this, we use our own threading model by necessity.) I am referring to OS threads and their general use in Tcl extensions.
Perhaps I am completely out here on my own and everyone else is talking specifically about "Tcl threads". If so then anyone who cares to may remove these comments.
AW This rather generalizing statement dating back to before 2002 by ?? would seem to imply that no one uses threads because it's not possible. This is not true at all. Take a look at the processes on your computer and the number of threads in each as an example. E.g. on my system I see firefox using 14 threads currently, to name just one well known app. This is almost a necessity already, and many think it will be the only way forward soon, see e.g. "The free lunch is over" by Herb Sutter [1 ].
Explain threading as programming model most like (modified) assembly line.
APN I'm afraid I have similar misgivings about coroutines.
[3 ] (Pulling Different Threads ), Cameron Laird, 2001-02, remarks on history and use of Tcl, particularly as compared to Perl and Python. It also references John Ousterhout's Thread paper old URL [while the previous link currently does not appear to be available, http://home.pacbell.net/ouster/threads.pdf is a PDF of the invited Talk that Dr. O gave which may correspond in some way to what was previoussly being referenced.] which argues for event-based programming rather than thread programming. b
TV 2003-11-06: It's understandable, since threads as opposed to processes normally would offer lightweightness, which under Tcl is probably not so important, and shared (global) variables and resources, which is however also possible on a per-event-switching basis. Note that synchronization usually takes place anyhow based on file or graphics events, though not strictly necessarily. A usual application for windows' threads I guess is graphics related (e.g. dialogs) which under Tk is relatively separated.
Point to critical info on testing (and debugging!) threaded apps.