Front page | perl.perl5.porters |
Postings from January 2006
shared SV change
From:
Dave Mitchell
Date:
January 6, 2006 13:38
Subject:
shared SV change
Message ID:
20060106213942.GS23210@iabyn.com
I've just committed
Change 26684 by davem@davem-cyril on 2006/01/06 21:13:12
make ithreads shared vars smaller/quicker by eliminating shared_sv
struct. Also document how it works.
Basically, shared variables used to consist of four things:
1) a proxy SV in each thread with attached magic that all pointed to:
2) a shared_sv struct, malloced from the shared memory pool, that contained a
mutex and condition variable, and a pointer to:
3) a single shared SV in a separate shared interpreter, which had
4) attached magic that pointed back to (2).
thread 1 [SV (1)][mg] -----\
thread 2 [SV (1)][mg] ------> [shared_sv (2)] ---> [SV (3)][mg (4)]
thread 3 [SV (1)][mg] -----/ ^ |
+-----------------------+
My change essentially eliminates (2) and (4):
thread 1 [SV (1)][mg] -----\
thread 2 [SV (1)][mg] ------> [SV (3)]
thread 3 [SV (1)][mg] -----/
The mutex and cond var in (2) are only used for explicit user-level
locking; eg in code like
my $foo : shared;
lock $foo;
If the variable is just being used to hold shared data and not for
locking, then (2) is superfluous.
By eliminating (2), we make the code simpler and faster and use less
memory. We can also then eliminate (4).
On the occasions where Perl-level locking is being used, we just attach
magic to the shared SV, containing a pointer to a (2)-like struct holding
the mutexes:
thread 1 [SV (1)][mg] -----\
thread 2 [SV (1)][mg] ------> [SV (3)][mg] ----> [locks (2)]
thread 3 [SV (1)][mg] -----/
The overall effect is that user-level locks and condition variables are
slightly slower, while everything else is quite a lot faster.
Dave.
--
That he said that that that that is is is debatable, is debatable.
-
shared SV change
by Dave Mitchell