[Python-Dev] Re: marking shared-ness

[Christian Tismer]

Greg Stein wrote:
> 
> On Wed, 19 Apr 2000, Christian Tismer wrote:
> > Greg Stein wrote:
> >...
> > > 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.
> 
> You don't have the thread state at incref/decref time.
> 
> And don't say "_PyThreadState_Current" or I'll fly to Germany and
> personally kick your ass :-)

A real temptation to see whether I can really get you to Germany :-))

...

Thanks for all the info.

> Linux has a kernel macro for atomic inc/dec, but it is only valid if
> __SMP__ is defined in your compilation context.

Well, and while it looks cheap, it is for sure expensive
since several caches are flushed, and the system is stalled
until the modified value is written back into the memory bank.

Could it be that we might want to use another thread design
at all? I'm thinking of running different interpreters in
the same process space, but with all objects really disjoint,
invisible between the interpreters. This would perhaps need
some internal changes, in order to make all the builtin
free-lists disjoint as well.
Now each such interpreter would be running in its own thread
without any racing condition at all so far.
To make this into threading and not just a flavor of multitasking,
we now need of course shared objects, but only those objects
which we really want to share. This could reduce the cost for
free threading to nearly zero, except for the (hopefully) few
shared objects.
I think, instead of shared globals, it would make more sense
to have some explicit shared resource pool, which controls
every access via mutexes/semas/whateverweneed. Maybe also that
we would prefer to copy objects into it over sharing, in order
to minimize collisions. I hope the need for true sharing
can be minimized to a few variables. Well, I hope.
"freethreads" could even coexist with the current locking threads,
we would not even need a special build for them, but to rethink
threading. 
Like "the more free threading is, the more disjoint threads are".

are-you-now-convinced-to-come-and-kick-my-ass-ly y'rs - 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