basic python threading question

[Tom]

Aahz & David,

Thanks for your detailed replies.  I see your point - that what I was
quoting applies to working at the C level.  I guess I was concerned that
this might apply to the Python level because I read that the interpreter
gives up the GIL every 10 bytecodes.  I don't know what level these
bytecodes operate at: if an operation on an immutable took more than one
bytecode then it could get preempted before the operation completed (eg.
perhaps updating the ref count is one bytecode?).

As for my comment about the inefficiency of threading on interpreters, you
point out that everything on an interpreter is slower.  Very true.  But,
while my program requires two seperate threads, the point of contact (ie.
shared data) is small, so it could be implemented as two single threaded
processes that communicate using shared buffers.  It sounds like the savings
achieved by eliminating the overhead of the Python threading layer (eg no
need to save the Python thread state on every switch) would more than make
up for the cost of shared buffers, assuming they are implemented well.  On
the other hand, the speed improvement would probably be small enough that it
wouldn't be worth the trouble.

And, yes, I am using the threading module, and it does seem straightforward.
I still have a theading bug somewhere, but I guess it has nothing to do with
the immutables, so I'll keep looking.

Tom.

"Aahz Maruch" <aahz at panix.com> wrote in message
news:8r2o2q$877$1 at panix3.panix.com...
> In article <Cc4B5.55776$dZ2.18164522 at news3.rdc1.on.home.com>,
> Tom <nospam at nospam.com> wrote:
> >"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.  Are
> >>>immutable objects inherently thread-safe in Python (even if the ref
count
> >>>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
binding
> >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
same
> >object, the reference count could end up being incremented only once
instead
> >of twice. "
>
> This is a different problem that occurs only when writing C extensions
> that interact with Python objects *and* the extension releases the
> Python global interpreter lock.  Let us know if this is your situation,
> and we can talk about ways to resolve it (the short answer is to acquire
> the GIL before updating Python objects).
>
> >I'm finding threading on Python to be more complicated than threading in
C.
>
> I'm betting that if you use a Pythonic threading system (i.e. by
> subclassing threading.Thread), you'll find threads in Python to be
> extremely simple.
>
> >It also seems that threading in any interpreted environment must have a
> >fairly heavy overhead, and so is best avoided.
>
> Yes and no.  You might as well remove your comment about threading and
> it'll be just as accurate -- interpreted environments like Python do
> indeed exact an overhead no matter what you're doing.  But just try
> writing your own dictionary type in C and see how much fun you have.
> --
>                       --- Aahz (Copyright 2000 by aahz at pobox.com)
>
> Androgynous poly kinky vanilla queer het    <*>
http://www.rahul.net/aahz/
> Hugs and backrubs -- I break Rule 6
>
> "Perhaps God rewards martyrs, but life seldom does..." --Ulrika O'Brien