Quotes edit
- Threads are for hangmen ;-)
- RS
- A computer is a state machine. Threads are for people who can't program state machines.
- attributed to Alan Cox (reputedly):
See Also edit
- Tcl and threads
- Why Threads are a Bad Idea (for most purposes)
- by John Ousterhout
- Threads, slow and buggy
, James Antill, 2006 - Re: AOLserver's documentation woes and its future, comp.web.aolserver, 2006-09-05
- UK 2006-09-26: mentioned on c.l.t with a dissemination of threadability of different scripting languages
- does my hardware controller need to use threads?
- Tcl event loop and threading, comp.lang.tcl, 2007-03-27
Reference edit
Description edit
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 [1].
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 [2]:
- Use of threads can be very deceptive. In many cases they appear to greatly simplify programming by allowing design in terms of simple autonomous entities focused on a single task. In fact in some cases they do simplify design and coding. However, in almost all cases they also make debugging, testing, and maintenance vastly more difficult and sometimes impossible.
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 [3] [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. bTV 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.
