S
Steven D'Aprano
A programmer had a problem, and thought Now he has "I know, I'll solve
two it with threads!" problems.
two it with threads!" problems.
D
Dave Angel
++10
I've been thinking about threads lately, and have come to the tentative
conclusion that they're a solution which has outlived its usefulness for
99% of the use cases. Much like the Windows 3.1 model of memory usage,
where all memory was shared, and apps promised not to step too hard on
each other. Or the "640k is more memory than any application will ever
need" notion.
When you multiprocess, everything is private except those things you
work at sharing. When you multithread, everything is shared, and you
promise not to intentionally do anything too nasty with the ability.
A
alex23
I laughed far far longer than I should have, cheers
T
Tim Chase
A newbie programmer had a problem and thought "I'll solve it by
posting on (e-mail address removed) and on Google Groups". And now we
have the problem of two threads...
Intentionally-misinterpreting'ly yours,
-tkc
C
Chris Angelico
And, when faced with problems of having two threads, the most obvious
solution is to add sleep() calls, so it looks like the above... Am I
dragging the analogy out too far?
ChrisA
D
Dave Angel
Naaah, too far would be trying to relate the GIL to KILL files. For
example, I avoid the google groups double-post syndrome by killfiling
any message with google-groups in the To: or CC: fields. 596 messages
in six months. I still get the second copy.
G
Grant Edwards
That took a few seconds -- must be the cold.
D
Dave Angel
Better minds than mine have tried very hard to eliminate the GIL, so for
now I consider that a feature of Python. If the GIL weren't needed for
the lowest levels of the interpreter, something else would be needed for
all the possible data structures that need atomic updates. Hello
semaphores, mutexes, etc. If threading were considered important in a
language, it'd have a way to declare an object sharable (default off),
and the low level code would go at full speed for any object not so
declared. But the language would then provide guarantees for the
standard objects that are marked as sharable. That's not current Python.
For other languages, I've done extensive work on projects with heavy
multithreading, and getting it right is extremely difficult. Another
way of putting it is that any non-trivial project with multithreading is
probably buggy.
M
Michael Torrie
The same applies to regular expressions, which is actually what the
expression was first used with years ago. Probably applies to just
about any technology. Including Java.
J
John Gordon
Steven cleverly worded it in such a way as to apply directly to threads.
The sentences are jumbled and interleaved, as if they were the output of
two threads that are not synchronized.
M
Michael Torrie
Very true! Guess I was too distracted by Python's warts to notice. Haha.
A
Antoine Pitrou
Steven D'Aprano said:
Host: Last week the Royal Festival Hall saw the first performance of a new
logfile by one of the world's leading modern programmers, Steven
"Two threads" D'Aprano. Mr D'Aprano.
D'Aprano: Hello.
Host: May I just sidetrack for one moment. This -- what shall I call it --
nickname of yours...
D'Aprano: Ah yes.
Host: "Two threads". How did you come by it?
D'Aprano: Well, I don't use it myself, but some of my friends call me "Two
Threads".
Host: And do you in fact have two threads?
D'Aprano: No, I've only got one. I've had one for some time, but a few
years ago I said I was thinking of spawning another, and since then some
people have called me "Two Threads".
Host: In spite of the fact that you only have one.
D'Aprano: Yes.
Host: And are you still intending to spawn this second thread?
D'Aprano: (impatient) No!
Host: ...To bring you in line with your epithet?
D'Aprano: No.
Host: I see, I see. Well to return to your program.
D'Aprano: Ah yes.
Host: Did you write this logfile in the thread?
D'Aprano: (surprised) No!
Host: Have you written any of your recent files in this thread of yours?
D'Aprano: No, no, not at all. It's just an ordinary daemon thread.
Host: I see, I see. And you're thinking of spawning this second thread to
write in!
D'Aprano: No, no. Look. This thread business -- it doesn't really matter.
The threads aren't important. A few friends call me Two Threads and that's
all there is to it. I wish you'd ask me about the logfile. Everybody talks
about the threads. They've got it out of proportion -- I'm a programmer.
I'm going to get rid of the thread. I'm fed up with it!
Host: Then you'll be Steven "No Threads" D'Aprano, eh?
T
Tim Golden
[... snip ...]
Brilliant, just brilliant.
TJG
C
Chris Angelico
Close, Host. He'd be Steven "No Marbles" D'Aprano.
*whistles innocently*
ChrisA
D
DJC
+ Applause
J
John Ladasky
Very nice! :^)
This problem isn't exclusive to Python, however. Other multi-threaded applications can produce jumbled output like this, even when the threads (processes?) are running on independent CPU's.
I use a very well-regarded application for molecular dynamics simulation: GROMACS, which I believe is written mostly in C (but there's even a little Fortran in it? And supposedly, this is critical to performance?). The GROMACS core program, mdrun, will grab as many CPUs as you allow it to use. The output of mdrun looks exactly like your little quip as each CPU reports back that it has started its piece of mdrun.