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.
> 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).
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?
[ ... thinking about the code ... ]
Nope. Won't work at all.
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.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
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