Front page | perl.perl5.porters |
Postings from November 1999
Re: This Week on perl5-porters (15--21 November 1999)
From:
Gurusamy Sarathy
Date:
November 22, 1999 09:09
Subject:
Re: This Week on perl5-porters (15--21 November 1999)
Message ID:
199911221713.JAA22490@activestate.com
On 22 Nov 1999 07:21:40 GMT, mjd@plover.com wrote in his summary:
[a summary from Dan Sugalski]
>Shared Interpreter threads (the current model)
>
>This threading model corresponds pretty closely to what most folks think of
>when they think of threads. There is a single, shared executable (or optree,
>in perl's case), and a single pool of variables. Any thread can see, and
Roughly half the variables are shared and the rest are distinct. For
example, the stack is distinct, but the symbol table isn't. intrpvar.h
contains the shared variables and thrdvar.h contains the ones that are
kept distinct for each thread. The major design flaw here being that there
is no comprehensive locking regime in the guts for accessing this shared
state; the programmer is supposed to sprinkle lock() in the perl code to
somehow manage this, but this is next to impossible given how these variables
are accessed in the guts.
Over time, we have been gradually moving variables from intrpvar.h into
thrdvar.h when we realized some things that were shared really ought not
to have been. Interpreter threads represent the logical end of this
migration; everything is local to the thread. :-)
>affect, anything that's in its lexical scope. Data sharing between threads
>is cheap, but the onus is on the programmer to maintain consistency.
>
>As an analogy, consider a thread a hamster, and your program as a giant
>habitrail. Starting another thread means releasing another hamster into the
>environment. Threads don't really collide (You ever see two hamsters get
>stuck in a habitrail tube?) but the only thing that keeps two or more
>hamsters from running on an exercise wheel at once is careful design of the
>set.
>
>Cloned interpreter threads (upcoming in 5.005_63)
>
>This threading model corresponds more to the traditional unix fork model.
>There is one copy of the optree per thread.
No. The optree is reference counted and shared between clones. By default
all mutable data that the optree accesses is distinct for each clone.
Think of this as being similar to how real fork() shares the text segment
but only copies the data segment.
Note that optree reference count manipulation is the only thing that needs
a lock (when nothing else is being shared).
> One thread can't see or affect
>anything in another thread unless that thing is explicitly shared. Data
>sharing and coordination between threads is mildly expensive and a bit
>cumbersome, but the onus is on the perl interpreter to keep one thread from
>messing with another thread's toys.
>
>Continuing the hamster analogy, creating a new thread in this model gets you
>a whole new, separate habitrail for your new hamster. The two habitrails may
>share exercise wheels, but only at very specific, explicit spots, and there
>are little exclusion gates built in so only one hamster can be on a wheel at
>once.
>
>My personal preference is a bit mixed--I want shared threads because they
>let me build all sorts of cheap, nifty tools (Threaded objects, and a
>subclassable Thread::Object, are I<trivial>. I know, I wrote a package to do
>it. One thread per object. Wheee!), but I think most folks (including me,
>when writing 'normal' code) are better off with the protection cloned
>threads get you.
>
>The trickier bit is under the hood. Getting perl thread-safe (which is to
>say, it won't core or segfault if the programmer doesn't sync access) is a
>PITA. I've already run through a couple of different plans--the first was
>paranoid and I<cost>, the second bloated libperl.so with a lot of shadow
>routines for XS, and the third I'm not gonna bother with if threads are dead
>anyway.
>
>It does chew up more memory, too. To do it right means each and every
>variable needs a mutex as well, otherwise you run into deadlock issues and
>uneccesary lock contention. 'Course, it makes $foo[time] cost even more than
>it does now. The alternative is &qt;just don't do that&qt;, but that's not
>really an option I like.
>
>Most of the p5p folks with an opinion prefers the forkish version. I think
>they're all wrong, of course, but that's just me. :-)
>----------------------------------------------------------------------------
>
>Thank you very much, Dan.
>
>Dan requested that Sarathy commit one way or the other on the existing
>threading model. Sarathy said that he wasn't sure yet, because he needs to
>see how the new way works out, but he guesses that Perl will go with the new
>way.
Sarathy
gsar@ActiveState.com
-
Re: This Week on perl5-porters (15--21 November 1999)
by Gurusamy Sarathy