begin quoting Lan Barnes as of Fri, Mar 30, 2007 at 02:57:26PM -0700: > > On Fri, March 30, 2007 2:43 pm, Stewart Stremler wrote: > > > There are many alternatives, but each one comes with its own set of > > tradeoffs (just like threads), so pointing at one or the other and > > saying "That one is BEST" is really just someone who wants to force > > their view on to everyone else. > > > > I think we need some more languages with built-in threading support, > > 'cuz the future is looking like multi-core shared-memory systems. We're > > going to be dealing with concurrent programming issues no matter what. > > We should be exploring that problem space, not avoiding it. > > I have assumed that there _are_ problems that must be solved with threads; > else why would they have been added to the Tcl core.
This sort of reasoning alwasy makes me want to grind my teeth. :) That being said... NO problem _must_ be solved with threads. They're merely a tool to produce a simpler design (within bounds) -- and it's all running as part of one huge sequential program anyway, it's on a Von Neumann machine. > I think it's fair for > an experienced programmer to say, if you find yourself reaching for > threads (or any other advanced feature), you would do well to return to > your analyses unless you have one of the bona fide problems that feature > was designed to cope with. Part of my problem is that I've not played with TCL in so long, or the threading features in TCL at all, I don't know what the warts are. But if the threading extensions are any good, then it's a matter of also asking oneself why _aren't_ you using threads, instead of <other technique>. Everything has a tradeoff. > Perhaps I'm less quick to think of this as arrogance (which I'm quick to > condemn) because I am so accustomed to the measured and courteous tone of > the Tcl lists. There is very little posturing or zealotry there. The > closest they come to smugness is the occasional "one of the nice things > about Tcl ..." statements. Heh. One of the nice things about threads is that it's conceptually simple to write producer/consumer logic all within the same program. This thread produces data and shoves it into a data structure, and that thread sucks data out of the data structure and consumes it. Simple. (Coroutines are *almost* as simple, except they still require language support or ugly hacks (strike 1), and they result in having to grok both sides of the problem at the same time (strike 2), and they're difficult to scale up to multiple producers or consumers (strike 3).) -- Some people have very high Hrair limits. Avoid depending on this. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
