This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Daniel Colascione
Recipients Daniel Colascione, amaury.forgeotdarc, belopolsky, davin, meador.inge, pitrou, rhettinger
Date 2017-10-01.17:55:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAKOZuet1zUdC9JEmpuh+8wZrud2PGZ2khBuqMWBY0owwKoNHuQ@mail.gmail.com>
In-reply-to <1506878388.13.0.213398074469.issue31654@psf.upfronthosting.co.za>
Content
On Oct 1, 2017 10:19 AM, "Raymond Hettinger" <report@bugs.python.org> wrote:

Raymond Hettinger <raymond.hettinger@gmail.com> added the comment:

> Compare-and-exchange is sufficient for avoiding the GIL contention
> I describe above.

If Python objects are involved, it is more complicated than you suggest.

Python objects are not involved. We're talking about memory manipulation on
the same level as ctypes.memmove.

Possibly, multiprocessing can offer a shared counter that creates integer
objects on demand and that offers guaranteed atomic increments and
decrements (as semaphores) do.

Why would it, when ctypes can provide generic functionality?

> one of the nice things about multiprocessing is avoiding
> GIL-introduced latency!

The primary way it achieves this benefit is by avoiding shared state
altogether.

Well, yes, but sometimes shared state is unavoidable, and it's best to
manipulate it as efficiently as possible.

----------
nosy: +davin, pitrou, rhettinger

_______________________________________
Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue31654>
_______________________________________
History
Date User Action Args
2017-10-01 17:55:33Daniel Colascionesetrecipients: + Daniel Colascione, rhettinger, amaury.forgeotdarc, belopolsky, pitrou, meador.inge, davin
2017-10-01 17:55:33Daniel Colascionelinkissue31654 messages
2017-10-01 17:55:33Daniel Colascionecreate