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 reasonably comparable to native ithreads (threads::shared).

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. See "TMPDIR" in forks::BerkeleyDB for more information.

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 with large shared datastructures, use a partition with a dedicated drive for temporary space usage. For best performance overall, use a ramdisk partition.

NOTES

Currently only SCALAR, ARRAY, and HASH shared variables are optimized. 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 correctly models the expected behavior of threads but deviates from undocumented forks behavior, where these events are atomic. Thus, don't forget to lock() your shared variable before using them concurrently in multiple threads; otherwise, results may not be what you expect.

Variables retain their pre-existing values after being shared. This may cause slow sharing of a variable if the variable contained many (large) values, or may trigger errors if the variable contained value(s) that are not valid for sharing. This differs from the default behavior of threads; see "Native threads 'to-the-letter' emulation mode" in forks if you wish to make forks::BerkeleyDB clear array/hash values just like native threads. Rule of thumb: always undef a variable before sharing it, unless you trust any pre-existing value(s) to be sharable.

TODO

Add support for shared circular references (REF).

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).

Allow for configurable lock limits (detault is 1000). Maybe simple DB_CONFIG file in env with: set_lk_max_locks N set_lk_max_objects N

Implement shared variable locks, signals, and waiting with BerkeleyDB.

AUTHOR

Eric Rybski <rybskej@yahoo.com>.