[Python-Dev] Re: marking shared-ness

[Greg Stein]

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/