0

I was going through David Beazley's GIL-related slides, in an attempt to understand what causes threading switching in Python. However, a lot of it is over my head.

http://www.dabeaz.com/python/UnderstandingGIL.pdf

It seems that after 100 ticks or so, the current thread releases the GIL, and will reacquire it if it's CPU Bound?

On the other hand if it sleeps or is I/O Bound, then another thread will acquire the GIL.

So if a thread is CPU bound it will keep reacquiring until it finished the task?

Improve this question

1 Answer 1

Reset to default
3

It will try to reacquire the GIL until it is done, or is paused at I/O or similar. However, if there are other CPU bound in the program, they will also try to acquire the GIL, so whenever the GIL is released, an arbitration is needed, to decide who will be allowed to get it.

But if there are no other threads ready to run (e.g. all others are waiting for I/O) then the running thread will get the lock everyt time. But then there will still be an overhead every 100 ticks for the release-reacquire dance.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

" an arbitration is needed, to decide who will be allowed to get it." Thank you. Do you happen how which thread gets to acquire the GIL is decided?
No, I don't for sure. But since the threads are handled by the OS, I think the OS is also responsible for the arbitration, so it could be OS dependent. (The Python VM could of course interfere, but I don't see why it should...)

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.