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> ? -- http://mail.python.org/mailman/listinfo/python-list
