[Python-Dev] Re: marking shared-ness

[Christian Tismer]

Greg Stein wrote:
> 
> On Wed, 19 Apr 2000, Christian Tismer wrote:
> >...
> > Too bad that we don't have incref/decref as methods.
> 
> This would probably impose more overhead than some of the atomic inc/dec
> mechanisms.
> 
> > The possible mutables which have to be protected could
> 
> Non-mutable objects must be protected, too. An integer can be shared just
> as easily as a list.

Uhh, right. Everything is mutable, since me mutate the refcount :-(

...
> Ah. Neat. "Automatic marking of shared-ness"
> 
> Could work. That initial test for the thread id could be expensive,
> though. What is the overhead of getting the current thread id?

Zero if we cache it in the thread state.

> [ ... thinking about the code ... ]
> 
> Nope. Won't work at all.

@#$%§!!-| yes-you-are-right - gnnn!

> There is a race condition when an object "becomes shared".
> 
> DECREF:
>   if ( object is not shared )
>      /* whoops! it just became shared! */
>      --(op)->ob_refcnt;
>   else
>      atomic_decrement(op)
> 
> To prevent the race, you'd need an interlock which is more expensive than
> an atomic decrement.

Really, sad but true.

Are atomic decrements really so cheap, meaning "are they mapped
to the atomic dec opcode"?
Then this is all ok IMHO.

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