develooper Front page | perl.ithreads | Postings from August 2002


Elizabeth Mattijsen
August 9, 2002 13:15
Message ID:
As promised on P5P, this is the first version of my proof of concept 
implementation for shared variables using a seperate thread.

Have fun and let me know if it helps you.

The uploaded file


has entered CPAN as

   file: $CPAN/authors/id/E/EL/ELIZABETH/Thread-Tie-0.01.tar.gz
   size: 8736 bytes
    md5: 22e61ca07a1d1de851d0aa500e007bc2

=head1 NAME

Thread::Tie - tie variables into a thread of their own


     use Thread::Tie;

     # use default thread + tieing + create thread when needed
     tie $scalar, 'Thread::Tie';
     tie @array, 'Thread::Tie';
     tie %hash, 'Thread::Tie';

     # create a thread beforehand
     my $thread = Thread::Tie::Thread->new;
     tie $scalar, 'Thread::Tie', {thread => $thread};

     # use alternate implementation
     tie $scalar, 'Thread::Tie',
      { thread => $thread, module => 'Own::Tie::Implementation' };

     # initialize right away
     tie $scalar, 'Thread::Tie', {}, 10;
     tie @array, 'Thread::Tie', {}, qw(a b c);
     tie %hash, 'Thread::Tie', {}, (a => 'A', b => 'B', c => 'C');


The standard shared variable scheme used by Perl, is based on tie-ing the
variable to some very special dark magic.  This dark magic ensures that
shared variables, which are copied just as any other variable when a thread
is started, update values in all of the threads where they exist as soon as
the value of a shared variable is changed.

Needless to say, this could use some improvement.

The Thread::Tie module is a proof-of-concept implementation of another
approach to shared variables.  Instead of having shared variables exist
in all the threads from which they are accessible, shared variable exist
as "normal", unshared variables in a seperate thread.  Only a tied object
exists in each thread from which the shared variable is accesible.

Through the use of a client-server model, any thread can fetch and/or update
variables living in that thread.  This client-server functionality is hidden
under the hood of tie().  So you could say that one dark magic (the current
shared variables implementation) is replaced by another dark magic.

I see the following advantages to this approach:

=over 2

=item memory usage

Shared variables in this approach are truly shared.  The value of a variable
only exists once in memory.  This implementation also circumvents the memory
leak that currently (threads::shared version 0.90) plagues any shared array
or shared hash access.

=item tieing shared variables

Because the current implementation uses tie-ing, you can B<not> tie a shared
variable.  The same applies for this implementation you might say.  However,
it B<is> possible to specify a non-standard tie implementation for use
B<within> the thread.  So with this implementation you B<can> C<tie()> a
shared variable.  So you B<could> tie a shared hash to a DBM file à la
dbmopen() with this module.


Of course there are disadvantages to this approach:

=over 2

=item pure perl implementation

This module is currently a pure perl implementation.  This is ok for a proof
of concept, but may need re-implementation in pure XS or in Inline::C for
production use.

=item tradeoff between cpu and memory

This implementation currently uses (much) more cpu than the standard shared
variables implementation.  Whether this would still be true when re-implemented
in XS or Inline::C, remains to be seen.

=back Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About