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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4