thread. question

[Christian Heimes]

Tim Wintle schrieb:
> Hi, 
> This is my first post here - google hasn't helped much but sorry if this
> has been asked before.
> 
> I've been wondering about some of the technicalities of locks in python
> (2.4 and 2.5 mainly).
> 
> I'm using the "old" thread module as (1) I prefer the methods and (2) It
> should be a tiny bit faster.

You shouldn't use the thread module directly. It's not meant to be used
by a user. Please stick to the threading module. You won't notice a
slowdown, trust me :)

> As far as I can see, the thread module is fairly much a direct wrapper
> around "PyThread_allocate_lock" etc. - defined in
> "thread_pthread.h" (took me ages to find the definitions in a header
> file!), so as far as I can tell the implementation is very closely
> wrapped around the system's threading implementation. 

The header files Python/thread_*.h contain the interface to your
system's threading libraries. One of the files is included conditionally
depending on your OS.

> Does that mean that every python thread is actually a real separate
> thread (for some reason I thought they were implemented in the
> interpreter)?

Yes, Python uses native threads, not green threads. However Python pure
code can't utilize more than one CPU per process. On order to use
multiple CPUs you have to use multiple processes or use C code that
doesn't use any Python API. Google for "GIL" if you are interested in
more information.

> Does that also mean that there is very little extra interpreter-overhead
> to using locks (assuming they very infrequently block)? Since if you use
> the thread module direct the code doesn't seem to escape from C during
> the acquire() etc. or am I missing something important?

You are correct. The overhead is minimal.

Christian