NAME

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

SYNOPSIS

use Thread::Tie; # use as early as possible for maximum memory savings

# 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');

DESCRIPTION

                 *** A note of CAUTION ***

This module only functions on Perl versions 5.8.0 and later.
And then only when threads are enabled with -Dusethreads.  It
is of no use with any version of Perl before 5.8.0 or without
threads enabled.

                 *************************

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:

memory usage

This implementation circumvents the memory leak that currently (threads::shared version 0.90) plagues any shared array or shared hash access.

tieing shared variables

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

Of course there are disadvantages to this approach:

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.

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.

IMPROVEMENTS

It should already be possible to tie handles, but this hasn't been tested yet.

It would be nice if you could start a bare thread, i.e. like when you start a script. Problem though is how are you going to communicate with that thread?

Examples should be added.

A more extensive test-suite should be added.

AUTHOR

Elizabeth Mattijsen, <liz@dijkmat.nl>.

Please report bugs to <perlbugs@dijkmat.nl>.

COPYRIGHT

Copyright (c) 2002 Elizabeth Mattijsen <liz@dijkmat.nl>. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

SEE ALSO

threads.