Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Python, multithreading & GIL

Reply
Thread Tools

Python, multithreading & GIL

 
 
Ivan Voras
Guest
Posts: n/a
 
      04-13-2004
I've read articles about it but I'm not sure I've got everything right. Here
are some statements about the subject that I'm not 100% sure about:

- when interpreter (cpython) is compiled with pthreads, python programs can
make use of multiple processors (other statements below are for
cpython+pthreads environment)?
- the GIL is only placed on global variables (and makes access to global
variables essentially serialized)? (--> if I don't use global variables, I'm
free from GIL?)
- python can make use of multiple IO accessess across threads: if one thread
does file.read(), others are not blocked by it?
- only one thread can do IO access: if one thread does file.read(), others
cannot (they wait until the 1st read() call ends)?
- all of the above stays the same for network IO (socket.read())?
- all of the above is true for any call to a C function?

Can someone say which statements are true, which are false (and an
explanation of what is more correct )?

Thanks!
 
Reply With Quote
 
 
 
 
Donn Cave
Guest
Posts: n/a
 
      04-13-2004
In article <c5h75f$277$(E-Mail Removed)>, Ivan Voras <(E-Mail Removed)>
wrote:

> I've read articles about it but I'm not sure I've got everything right. Here
> are some statements about the subject that I'm not 100% sure about:
>
> - when interpreter (cpython) is compiled with pthreads, python programs can
> make use of multiple processors (other statements below are for
> cpython+pthreads environment)?


Depends on what you mean by "make use of".

> - the GIL is only placed on global variables (and makes access to global
> variables essentially serialized)? (--> if I don't use global variables, I'm
> free from GIL?)


No, it's a global variable that serializes thread execution.

> - python can make use of multiple IO accessess across threads: if one thread
> does file.read(), others are not blocked by it?


Yes, because file.read releases the lock before it calls its
underlying C function (and acquires it again afterwards before
proceeding.)

> - all of the above stays the same for network IO (socket.read())?


Yes.

> - all of the above is true for any call to a C function?


No, C function interfaces are not required to release the lock,
and in fact might reasonably elect not to. For example, a function
that does some trivial computation, like peeking at some value in
library state, would incur a lot of unnecessary overhead by releasing
the lock. Other interfaces might neglect to release the lock just
because the author didn't care about it.

Donn Cave, http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Ivan Voras
Guest
Posts: n/a
 
      04-13-2004
Donn Cave wrote:

>>- when interpreter (cpython) is compiled with pthreads, python programs can
>>make use of multiple processors (other statements below are for
>>cpython+pthreads environment)?

>
>
> Depends on what you mean by "make use of".


"Simultaneusly execute different threads on different processors". I
mean all kinds of threads: IO-based and computation-based.

>>- the GIL is only placed on global variables (and makes access to global
>>variables essentially serialized)? (--> if I don't use global variables, I'm
>>free from GIL?)

>
> No, it's a global variable that serializes thread execution.


Now I'm puzzled - how is that different from GIL?

For example: if I have two or more threads that do numerical and string
computations not involving global variables, will they execute without
unexpected locking?
 
Reply With Quote
 
Jarek Zgoda
Guest
Posts: n/a
 
      04-13-2004
Ivan Voras <ivoras@__geri.cc.fer.hr> pisze:

>>>- the GIL is only placed on global variables (and makes access to global
>>>variables essentially serialized)? (--> if I don't use global variables, I'm
>>>free from GIL?)

>>
>> No, it's a global variable that serializes thread execution.

>
> Now I'm puzzled - how is that different from GIL?
>
> For example: if I have two or more threads that do numerical and string
> computations not involving global variables, will they execute without
> unexpected locking?


I think it's a best time to write some definite documet, how GIL can
affect our programs and how to avoid headaches when using threading with
Python. I know what this acronym (GIL) means, I know the definition, but
I have very limited knowledge on threading issues in languages, that use
VM environments.

Anyone?

--
Jarek Zgoda
http://jpa.berlios.de/
 
Reply With Quote
 
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
Guest
Posts: n/a
 
      04-13-2004
Ivan Voras wrote:
>>> - when interpreter (cpython) is compiled with pthreads, python
>>> programs can make use of multiple processors (other statements below
>>> are for cpython+pthreads environment)?

>>
>>
>>
>> Depends on what you mean by "make use of".

>
>
> "Simultaneusly execute different threads on different processors". I
> mean all kinds of threads: IO-based and computation-based.


In Python, no two threads will ever simultaneously interprete byte code
instructions.

It might be that two threads started in Python simultaneously execute
non-Python code (like a C extension), or that one thread blocks in IO
and the other executes byte code. However, once one thread executes
Python byte code, no other thread in the same process will do so.

>
>>> - the GIL is only placed on global variables (and makes access to
>>> global variables essentially serialized)? (--> if I don't use global
>>> variables, I'm free from GIL?)

>>
>>
>> No, it's a global variable that serializes thread execution.

>
>
> Now I'm puzzled - how is that different from GIL?


That is the GIL: a global variable that serializes thread execution.

However, it is *not* *only* placed on global variables. It is placed
on any kind of byte code, and data access, with the few exceptions
of long-running C code. So if you have two functions

def thread1():
while 1ass

def thread2():
while 1ass

and you run them in two seperate threads, you will *not* be free from
the GIL. Both loops hold the GIL while executing, and give it up every
100 or so byte code instructions.

> For example: if I have two or more threads that do numerical and string
> computations not involving global variables, will they execute without
> unexpected locking?


Depends on what you expect. There will be locking, and the threads will
not use two processors effectively (i.e. you typically won't see any
speedup from multiple processors if your computation is written in
Python)

Regards,
Martin

 
Reply With Quote
 
Ivan Voras
Guest
Posts: n/a
 
      04-13-2004
Martin v. L÷wis wrote:


> In Python, no two threads will ever simultaneously interprete byte code
> instructions.
>
> It might be that two threads started in Python simultaneously execute
> non-Python code (like a C extension), or that one thread blocks in IO
> and the other executes byte code. However, once one thread executes
> Python byte code, no other thread in the same process will do so.


Thank you, your post gave the sort of answers I was looking for.

 
Reply With Quote
 
Donn Cave
Guest
Posts: n/a
 
      04-13-2004
In article <c5hd8n$1i3$(E-Mail Removed)>,
Ivan Voras <ivoras@__geri.cc.fer.hr> wrote:
> Donn Cave wrote:
> > >>- when interpreter (cpython) is compiled with pthreads, python programs can
> >>make use of multiple processors (other statements below are for
> >>cpython+pthreads environment)?

> >
> >
> > Depends on what you mean by "make use of".

>
> "Simultaneusly execute different threads on different processors". I
> mean all kinds of threads: IO-based and computation-based.


I'm sorry, when I wrote that I expected that I would be saying
more about that later on, but maybe I went over that a little
too light and I didn't mean to be cryptic. My point is that
a Python program is (at least) two layers: the part actually
written in Python, and the part written in C - modules written
in C and all the library functions they call. A Python program
can make use of multiple processors. Only one processor can
actually be executing the interpreter, but the interpreter may
be calling an external cryptography function in another thread,
and listening to a socket in another, etc.

I/O is a natural case of this - Python can't do any kind of I/O
on its own, so we can reasonably expect concurrent I/O. Computation
depends.

> >>- the GIL is only placed on global variables (and makes access to global
> >>variables essentially serialized)? (--> if I don't use global variables,
> >>I'm
> >>free from GIL?)

> >
> > No, it's a global variable that serializes thread execution.

>
> Now I'm puzzled - how is that different from GIL?


I meant, the GIL isn't placed on global variables, but it is one.

> For example: if I have two or more threads that do numerical and string
> computations not involving global variables, will they execute without
> unexpected locking?


They will execute serially. I believe the interpreter schedules
threads for some number of instructions, so each thread won't
have to run to completion before the next one can execute - they'll
all probably finish about the same time - but there will be only
one interpreter thread executing at any time.

This has been known to bother people, and some years back a very
capable programmer on the Python scene at the time tried to fix
it with a version of Python that was `free threaded.' I think
the reason it's not the version of Python we're using today is
1. It's a hard problem, and
2. It doesn't make that much practical difference.

That's my opinion, anyway. There are a few lengthy discussions
of the matter in the comp.lang.python archives, for anyone who
wants to see more opinions.

Donn Cave, (E-Mail Removed)
 
Reply With Quote
 
Project2501
Guest
Posts: n/a
 
      04-13-2004

surely there is a case for a python VM/interpreter to be able to handle
threads without GIL. That is, map them to whatever underlying OS
facilities are available, and only of they are not available, do bytecode
interleaving. After all, python relies on OS facilities for many other
tasks.


 
Reply With Quote
 
Donn Cave
Guest
Posts: n/a
 
      04-14-2004
In article <(E-Mail Removed)> ,
Project2501 <(E-Mail Removed)> wrote:

> surely there is a case for a python VM/interpreter to be able to handle
> threads without GIL. That is, map them to whatever underlying OS
> facilities are available, and only of they are not available, do bytecode
> interleaving. After all, python relies on OS facilities for many other
> tasks.


Python definitely provides meaningful support for several
types of operating systems threads, including POSIX, and
the way I understand you, it does what you say. It's not
like the way some other interpreted languages (or Python
has in some version of Stackless) implement threads inside
a single OS interpreter thread, these are real OS threads
and your Python code (i.e., the interpreter) runs "in" them.

It's just that part of the support for concurrency is a
lock that protects Python internal data structures from
unsound concurrent access. That's the reason for the GIL.

And as I asserted, it isn't a significant problem in practice.

Donn Cave, (E-Mail Removed)
 
Reply With Quote
 
Ivan Voras
Guest
Posts: n/a
 
      04-14-2004
Donn Cave wrote:

> It's just that part of the support for concurrency is a
> lock that protects Python internal data structures from
> unsound concurrent access. That's the reason for the GIL.
>
> And as I asserted, it isn't a significant problem in practice.


Except if you're planning for multiple processors

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Jython and GIL bboman@research.panasonic.com Python 2 02-09-2004 04:59 PM
RE: GIL in the new glossary Luis P Caamano Python 21 10-05-2003 12:24 AM
GIL in the new glossary Luis P Caamano Python 6 10-04-2003 10:23 PM
RE: GIL in the new glossary Tim Peters Python 2 10-03-2003 07:04 PM
extension call backs and the GIL Robin Becker Python 6 09-29-2003 06:36 PM



Advertisments