NAME
forks::BerkeleyDB::shared - high-performance drop-in replacement for threads::shared
SYNOPSYS
use forks::BerkeleyDB;
use forks::BerkeleyDB::shared;
my $variable : shared;
my @array : shared;
my %hash : shared;
share( $variable );
share( @array );
share( %hash );
lock( $variable );
cond_wait( $variable );
cond_wait( $variable, $lock_variable );
cond_timedwait( $variable, abs time );
cond_timedwait( $variable, abs time, $lock_variable );
cond_signal( $variable );
cond_broadcast( $variable );DESCRIPTION
forks::BerkeleyDB::shared is a drop-in replacement for threads::shared, written as an extension of forks::shared. The goal of this module improve upon the core performance of forks::shared at a level comparable to native ithreads (threads::shared).
Depending on how you architect your data processing, as well as how your target platform filesystem has been configured and tuned, you should expect to achieve around 75% the performance of native ithreads for all shared variable operations. Given that this module is written entirely in pure perl, this is an outstanding benchmark and is a testament to the performance of BerkeleyDB. Performance could likely be further improved by migrating some of the code to XS (especially some of the operator methods in tied module packages).
USAGE
See forks::shared for common usage information.
Location of database files
This module will use $ENV{TMPDIR} (unless taint is on) or /tmp for all back-end database and other support files. For the most part, BerkeleyDB will use shared memory for as much frequently accesed data as possible, so you probably won't notice drive-based performance hits. For optimal performance, use a partition with a physical drive dedicate for tempory space usage.
NOTES
Forks 0.19 or later is required to support transparent blessing across threads. This feature will be silently disabled if this requirement is not met.
Currently optimizes SCALAR, ARRAY, and HASH shared variables. HANDLE type is supported using the default method implemented by forks::shared.
Shared variable access and modification are NOT guaranteed to be handled as atomic events. This deviates from undocumented forks behavior, where all these events are atomic, but it correctly models the expected behavior of threads. Thus, don't forget to lock() your shared variable before using them concurrently in multiple threads; otherwise, results may not be what you expect.
When share is used on arrays, hashes, array refs or hash refs, any data they contain will be lost. This correctly models the expected behavior of threads, but not (currently) of forks.
TODO
Monitor number of connected shared variables per thread and dynamically disconnect uncommonly used vars based on last usage and/or frequency of usage (to meet BDB environment lock limits).
Implement shared variable locks, signals, and waiting with BerkeleyDB.
AUTHOR
Eric Rybski <rybskej@yahoo.com>.
COPYRIGHT
Copyright (c) 2006 Eric Rybski <rybskej@yahoo.com>. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.