[Python-Dev] Re: marking shared-ness

[Greg Stein]

On Thu, 20 Apr 2000, Christian Tismer wrote:
>...
> > 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.

Yes, Bill mentioned that yesterday. Important fact, but there isn't much
you can do -- they must be atomic.

> 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".

No. Now you're just talking processes with IPC. Yes, they happen to run in
threads, but you got none of the advantages of a threaded application.

Threading is about sharing an address space.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/