[Python-Dev] marking shared-ness (was: baby steps for free-threading)

[Christian Tismer]

Greg Stein wrote:
> 
> On Wed, 19 Apr 2000, Salz, Rich wrote:
> > >In my experience, allowing/requiring programmers to specify sharedness is
> > >a very rich source of hard-to-find bugs.
> >
> > My experience is the opposite, since most objects aren't shared. :)
> > You could probably do something like add an "owning thread" to each object
> > structure, and on refcount throw an exception if not shared and the current
> > thread isn't the owner. Not sure if space is a concern, but since the object
> > is either shared or needs its own mutex, you make them a union:
> >       bool shared;
> >       union {
> >               python_thread_id_type id;
> >               python_mutex_type m;
> >       };
> >
> >
> >   (Not saying I have an answer to
> > the performance hit of locking on incref/decref, just saying that the
> > development cost of 'shared' is very high.)
> 
> Regardless of complexity or lack thereof, any kind of "specified
> sharedness" cannot be implemented.
> 
> Consider the case where a programmer forgets to note the sharedness. He
> passes the object to another thread. At certain points: BAM! The
> interpreter dumps core.
> 
> Guido has specifically stated that *nothing* should ever allow that (in
> terms of pure Python code; bad C extension coding is all right).
> 
> Sharedness has merit, but it cannot be used :-(

Too bad that we don't have incref/decref as methods.

The possible mutables which have to be protected could
in fact carry a thread handle of their current "owner"
(probably the one who creted them), and incref would
check whether the owner is still same.
If it is not same, then the owner field would be wiped,
and that turns the (higher cost) shared refcounting on,
and all necessary protection as well.
(Maybe some extra care is needed to ensure that this info
isn't changed while we are testing it).

Without inc/dec-methods, something similar could be done,
but every inc/decref will be a bit more expensive since
we must figure out wether we have a mutable or not.

ciao - chris

-- 
Christian Tismer             :^)   <mailto:tismer@appliedbiometrics.com>
Applied Biometrics GmbH      :     Have a break! Take a ride on Python's
Kaunstr. 26                  :    *Starship* http://starship.python.net
14163 Berlin                 :     PGP key -> http://wwwkeys.pgp.net
PGP Fingerprint       E182 71C7 1A9D 66E9 9D15  D3CC D4D7 93E2 1FAE F6DF
     where do you want to jump today?   http://www.stackless.com