Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

[robert]

Martin v. Löwis wrote:
> robert schrieb:
>> 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.

( meant: a lock to prevent multiple Interpreters accessing concurrently the hot shared/tunneled objects )

>> ---- 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.

Thanks for that info. That is interesting.
Thus even on x86 currently this LOCK is not used  (just	(op)->ob_refcnt++) )

Reading this I got pinched: 
In win32ui there are infact Py_INC/DECREF's outside of the GIL !
And I have a severe crash problem with threaded apps - the problem is only only on dual cores !
That pointer probably will end a long search...


robert


PS: Besides: what are speed costs of LOCK INC <mem> ?