Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?
"Martin v. Löwis"
martin at v.loewis.de
Sat Nov 4 00:40:27 CET 2006
> in combination with some simple locking (anyway necessary) I don't see a
> problem in ref-counting.
In the current implementation, simple locking isn't necessary.
The refcounter can be modified freely since the code modifying
it will always hold the GIL.
> ---- Question Besides: do concurrent INC/DEC machine OP-commands
> execute atomically on Multi-Cores as they do in Single-Core threads?
Not necessarily, no. On x86, you need to prefix the instruction
with the LOCK prefix for it to become atomic. Otherwise, the
two necessary read/write cycles to main memory may interleave
with the memory operations of another processor.
On other processors, INC <mem> might not exist at all as an
instruction; when you only have register add, then implementing
an atomic increment is a challenge. That's why the Windows API
provides you with an atomic increment function as part of the
operating system API.
More information about the Python-list