Skip to content

gh-125997: suggest efficient alternatives for time.sleep(0) #128752

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jan 18, 2025
Merged

gh-125997: suggest efficient alternatives for time.sleep(0) #128752

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
271dfd9
Suggest efficient alternatives for `time.sleep(0)`.
picnixz Jan 12, 2025
178b1b5
address Victor's review
picnixz Jan 13, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion Doc/library/os.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5411,6 +5411,8 @@ information, consult your Unix manpages.
The following scheduling policies are exposed if they are supported by the
operating system.

.. _os-scheduling-policy:

.. data:: SCHED_OTHER

The default scheduling policy.
Expand Down Expand Up @@ -5514,7 +5516,7 @@ operating system.

.. function:: sched_yield()

Voluntarily relinquish the CPU.
Voluntarily relinquish the CPU. See :manpage:`sched_yield(2)` for details.


.. function:: sched_setaffinity(pid, mask, /)
Expand Down
11 changes: 10 additions & 1 deletion Doc/library/time.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -385,6 +385,8 @@ Functions
The suspension time may be longer than requested by an arbitrary amount,
because of the scheduling of other activity in the system.

.. rubric:: Windows implementation

On Windows, if *secs* is zero, the thread relinquishes the remainder of its
time slice to any other thread that is ready to run. If there are no other
threads ready to run, the function returns immediately, and the thread
Expand All @@ -393,12 +395,19 @@ Functions
<https://learn.microsoft.com/windows-hardware/drivers/kernel/high-resolution-timers>`_
which provides resolution of 100 nanoseconds. If *secs* is zero, ``Sleep(0)`` is used.

Unix implementation:
.. rubric:: Unix implementation

* Use ``clock_nanosleep()`` if available (resolution: 1 nanosecond);
* Or use ``nanosleep()`` if available (resolution: 1 nanosecond);
* Or use ``select()`` (resolution: 1 microsecond).

.. note::

To emulate a "no-op", use :keyword:`pass` instead of ``time.sleep(0)``.

To voluntarily relinquish the CPU, specify a real-time :ref:`scheduling
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of just repeating "relinquish the CPU" from sched_yield's docs, I think it's worth being more specific. Something like "allow other threads to execute" and/or "temporarily release the GIL" could be useful.

The other issue here is that sched_yield is specific to Unix systems--what are Windows users supposed to use if they want to explicitly let another thread take the GIL, if not time.sleep()?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They use time.sleep(0). The note is for the Unix section. On Windows, Sleep(0) relinquishes the CPU: https://learn.microsoft.com/en-gb/windows/win32/api/synchapi/nf-synchapi-sleep?redirectedfrom=MSDN.

A value of zero causes the thread to relinquish the remainder of its time slice to any other thread that is ready to run. If there are no other threads ready to run, the function returns immediately, and the thread continues execution. Windows XP: A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003.

Copy link
Member Author

@picnixz picnixz Jan 13, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I can add "On non-Windows platforms" if you want?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, got it. I didn't see that this was explicitly the Unix section, I thought you were just reformatting. (I still do think we should mention the GIL here, but it's up to you.)

Anyways, this is out of the scope of this PR, but this kind of situation probably isn't ideal for users. You have to maintain two code paths: one to call time.sleep(0) on Windows, and then os.sched_yield on Linux. Do you think it's a good idea to add a dedicated function for that in a follow-up issue?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know. I don't know much about Windows users but maybe os.sched_yield() could, call Sleep(0) on Windows? Considering that no one ever complained about this specifically (what users complain is that it takes too much time, and probably don't really care about what we're actually doing behind the scene), I think we shouldn't bother for now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably because it's difficult to notice--in practice, people use time.sleep(0) on both systems, because the performance issue on Linux generally isn't clear, especially for multithreaded programs. My theory is that providing a dedicated function will get people to notice the issue more. I'm speculating though!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could open a DPO thread for that. Namely, whether to provide a Windows-equivalent of os.sched_yield() but that does not have the meaning of a scheduling policy.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO you're trying to solve a non-existent problem. time.sleep(0) is efficient and does what the developer expects. It's just that os.sched_yield() can be even more efficient on Linux. IMO time.sleep(0) is the portable "pass the CPU to another thread", even if it's not "optimal" (on Linux).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you really need the most efficient "yield":

if hasattr(os, 'sched_yield'):
    def portable_efficient_yield():
        os.sched_yield()
else:
    def portable_efficient_yield():
        time.sleep(0)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I made a DPO thread, feel free to post concerns there: https://discuss.python.org/t/platform-agnostic-yielding-of-the-gil/77006/

I'm in favor of a function other than time.sleep(0) for yielding, because it's not particularly clear that sleep(0) would actually do something useful, but we're killing two birds with one stone because of the performance.

policy <os-scheduling-policy>` and use :func:`os.sched_yield` instead.

.. audit-event:: time.sleep secs

.. versionchanged:: 3.5
Expand Down
Loading