A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2009-May/089754.html below:

[Python-Dev] Making the GIL faster & lighter on Windows

[Python-Dev] Making the GIL faster & lighter on Windows [Python-Dev] Making the GIL faster & lighter on Windows"Martin v. Löwis" martin at v.loewis.de
Wed May 27 01:24:02 CEST 2009
> If you define fairness in this context as not starving other threads
> while consuming resources, that is built into the interpreter via
> sys.setcheckinterval() and also anywhere the GIL is released for I/O.
> What might be interesting is to see if releasing a critical section
> and immediately re-acquiring it every _Py_CheckInterval bytecode
> operations behaves in a similar manner (see ceval.c, line 869). My
> best guess right now is that it will behave as expected when not using
> the spin-based critical section. AFAIK, the kernel processes waiters
> in a FIFO manner without regard to priority. Because a guarantee of
> mutual exclusion is absolutely necessary, it's up to applications to
> provide fairness. Python does a decent job of this.

No: fairness in mutex synchronization means that every waiter for the
mutex will eventually acquire it; it won't happen that one thread
starves waiting for the mutex. This is something that the mutex needs to
provide, not the application.

Regards,
Martin
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4