python threads are about as straightforward as possible, from my experience. They are pretty much a direct wrapper of pthreads, and thereby expose the basic mechanisms of dealing with shared stuff in a concurrent environment (minus fancy keywords ). I can't think of any simpler way to teach someone about concurrency mechanics.
.. and on my core duo laptop, threading in python immediately hops onto the second core, which is very useful when i am writing a quick script to do some intensive task once (as opposed to writing a c program to do it). Of course, when i do something stupid i have a threaded python program i can't just rely on the cpu time of core numero dos to lazily fire a signal :) On 4/2/07, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
Lan Barnes wrote: > While you guys have been using this thread to rhaposidize about that which > is new, shiny, hip slick and cool, I've been shaking my head and wondering > if you really missed my original point that completely: that maybe 98% of > the time, simple and direct is better than hip, slick and cool. And what you are failing to get from my point is that I am not staring at concurrency because it's "hip, slick, and cool." I am staring at concurrency because performance is moving from "2x faster every 18 months" to "2x more cores *at the same speed* every 18 months". > Tcl/Tk gives me all that. I hope I live a long, productive life without > ever having to write a line of threaded code, and with Tcl, I probably > have that option. Ah, this is the misunderstanding. Some of us believe, at this point, you don't get a choice. The speed formulation of Moore's law is dead; the cost/area formulation of Moore's law still holds though. Either your language copes with multiple concurrency abstractions, or it is at a dead end. Maybe *you* don't write threaded code, but the package and library developers will have to. We can certainly argue about that. >> I have helped debug more than a few Tcl/Tk programs for beginners where >> some UI callback sets a variable in the wrong order relative to the >> mainline program flow. And this is for exactly *2* threads. Try >> explaining to them what just happened; it's really hard. It shouldn't >> be so blasted hard. I note that you ignored this. You shouldn't have. It is at the heart of the problem. Until I have a language that college students can use to program concurrency and not get lost in a maze of subtle, evanescent, unreproduceable bugs, there is no language that handles concurrency well. My opinion on this subject is that threads are like C++. Superficially it's a good idea, but the cognitive load is too high for heavy use. Just as we have figured out that C++ has specific usage that it is good for (performance oriented hardware codes) and specific usage that it is not (dynamic behavior and code malleability), we will do the same for concurrency. And, why are you taking this as an attack on Tcl/Tk? It's not. I'm sure their implementation of threads is fine. What I'm saying is that language designers need to look beyond the assumption that "threads == concurrency". -a -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
-- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
