basic python threading question
nospam at nospam.com
Sat Sep 30 00:32:32 CEST 2000
"Donn Cave" <donn at u.washington.edu> wrote in message
news:8r2vhj$bsl2$1 at nntp6.u.washington.edu...
> Quoth "Tom" <nospam at nospam.com>:
> | "Aahz Maruch" <aahz at panix.com> wrote in message
> | news:8r2hdl$6rr$1 at panix6.panix.com...
> |> In article <q_IA5.42927$dZ2.15588642 at news3.rdc1.on.home.com>,
> |> Tom <nospam at nospam.com> wrote:
> |>| This would be a problem for threading, unless all atomic objects are
> |>| thead-safe. Now, all atomic objects appear to me to be immutable.
> |>| immutable objects inherently thread-safe in Python (even if the ref
> |>| change)?
> |> Yes, immutable objects are thread-safe. Remember that assignment in
> |> Python is a binding operation, not a modification operation.
> | But, even an immutable object has its reference count modified by a
> | operation. And this sounds like a problem to me, since (quoting from
> | section 8.1 of API Ref):
> | "when two threads simultaneously increment the reference count of the
> | object, the reference count could end up being incremented only once
> | of twice. "
> In the present implementation, though, if that could actually happen it
> would be through a bug at the C level, not in Python. The interpreter
> has a global lock that prevents operations like assign/bind from happening
> in two concurrent threads. Correctly implemented modules can allow
> concurrent execution, but only where all but one thread are in external
> This is the kind of thing you need to know.
> As another poster has already mentioned, thread safety isn't really about
> different kinds of objects. Mutable vs. immutable isn't that useful of
> a distinction. How about a file descriptor open on a UNIX pipe? it's
> just an integer, and of course you can use it for arithmetic all you want,
> but don't let two threads write to it at once.
> | I'm finding threading on Python to be more complicated than threading in
> | It also seems that threading in any interpreted environment must have a
> | fairly heavy overhead, and so is best avoided.
> Threading is best avoided, period. I mean, if you can do approximately
> the same thing without threads, then you would have to be insane to use
> threads. But I'm posting this from a multithreaded program, written in
> python, at the moment I count 15 threads. There's no overhead on this
> 132Mhz computer, and Python doesn't make it more difficult nor does it
> make it easier. The use of threads adds a dimension to the complexity
> of the program, that's all. The overhead is in your head.
Yes, I agree, but I felt it was necessary. One thread is for the GUI, the
other is for code that gets traced, so it is going into a trace handler.
This is one of those cases where it could be done with one thread, but this
would create a very ackward design.
More information about the Python-list