[Python-Dev] Reworking the GIL

[Antoine Pitrou]

Martin v. Löwis <martin <at> v.loewis.de> writes:
> 
> I've looked at this part of the implementation, and have a few comments.
> a) why is gil_interval a double? Make it an int, counting in
>    microseconds.

Ok, I'll do that.

> b) notice that, on Windows, minimum wait resolution may be as large as
>    15ms (e.g. on XP, depending on the hardware). Not sure what this
>    means for WaitForMultipleObjects; most likely, if you ask for a 5ms
>    wait, it waits until the next clock tick. It would be bad if, on
>    some systems, a wait of 5ms would mean that it immediately returns.

I'll let someone else give an authoritative answer. I did the Windows version
mainly by reading online MSDN docs, and testing it worked fine in an XP VM.

Anyway, here is what the online docs have to say :

« The system clock "ticks" at a constant rate. If the time-out interval is less
than the resolution of the system clock, the wait may time out in less than the
specified length of time. If the time-out interval is greater than one tick but
less than two, the wait can be anywhere between one and two ticks, and so on. »

So it seems that the timeout always happens on a Windows tick boundary, which
means that it can immediately return, but only very rarely so and never more
than once in a row...

> c) is the gil_drop_request handling thread-safe? If your answer is
>    "yes", you should add a comment as to what the assumptions are of
>    this code (ISTM that multiple threads may simultaneously attempt
>    to set the drop request, overlapping with the holding thread actually
>    dropping the GIL).

The gil_drop_request is volatile mainly out of precaution, but it's probably not
necessary. It is only written (set/cleared) when holding the gil_mutex; however,
it can be read while not holding that mutex. Exceptionally reading the "wrong"
value would not have any adverse consequences, it would just decrease the
switching quality at the said instant.

Regards

Antoine.