[runT1ME]

I don't think there's anything to prevent more than one thread from being scheduled at any time. They just block when trying to run concurrently because of the GIL.

>I'm not sure if you misunderstood the mail. The constant locking would only be used if they were running in parallel.

No, I'm saying that the GIL is constant locking. You still have two threads being run concurrently on (possibly) two separate cores accessing the same cache lines. They just cannot actually run in parallel. I have no idea how the GIL time slices between the two threads, so what i'm saying is completely possible.

However, below my original post meastham correctly pointed out the GIL does prevent cache thrashing where updates to shared memory might go back and fourth multiple times unnecessarily. So it's not as bad as I was imagining.

[lambda_cube]

Yes, you are right that the OS can schedule two Python threads to run at the same time, it's just that one of them will only run a few instructions and then block, just not any Python instructions. I hadn't really thought that through thoroughly, thanks for pointing it out.

Ah, I see now what you meant with constant locking. I interpreted your words as "constant" as in happening all the time as would be the case with fine grained locks instead of one long-lasting, global lock.