[Python-Dev] deja-vu .. python locking

[Phillip J. Eby]

At 07:08 PM 9/18/2006 +0200, Martin Devera wrote:
> >> So that you are right. It is not RCU. It only uses similar technique 
> as RCU
> >> uses for free-ing old copy of data.
> >>
> >> It is based on assumption that an object is typicaly used by single 
> thread.
> >
> > Which thread owns builtins?  Or module dictionaries?  If two threads are
> > running the same function and share no state except their globals, won't
> > they constantly be thrashing on the module dictionary?  Likewise, if the
> > same method is running in two different threads, won't they thrash on the
> > class dictionary?
>
>As I've written in "Big reader lock" paragraph of the original proposal, these
>objects could be handled by not blocking in read path and wait for all other
>threads to "come home" before modifying.

Changing an object's reference count is modifying it, and most accesses to 
get the dictionaries themselves involve refcount changes.  Your plan, so 
far, does not appear to have any solution for reducing this overhead.

Module globals aren't so bad, in that you'd only have to lock and refcount 
when frames are created and destroyed.  But access to class dictionaries to 
obtain methods happens a lot more often, and refcounting is involved there 
as well.

So, I think for your plan to work, you would have to eliminate reference 
counting, in order to bring the lock overhead down to a manageable level.