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).
The thread model implemented in the Tcl thread extension goes a long way toward alleviating the problems that arise with threads. See Tcl and threads for more information.
Note: There is very little code out there in the "real world" that is actually thread-safe. The gnu C++ lib has unsafe code! Thread behaviour is treacherously platform dependent.
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.
Windows users are on their own. Microsoft could whimsically implement any old craziness and you'd never know.
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 [L1 ].
Explain threading as programming model most like (modified) assembly line.
KBK 2003-06-21: Even the designers of Java, where threads are ubiquitous, appear to have been distinctly ambivalent about them. From [L2 ]:
APN I'm afraid I have similar misgivings about coroutines.
Pulling Different Threads (old URL ), 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 [L3 ] [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.