if i declare my $data : shared within an if { } block, does the shared value go out of scope after the block?
Yes, it will go out of scope--but it will not cease to exists if
- anything holds a reference to it.
- if it is a reference and you have assigned it to something who's scope is wider.
That's not a good explanation. The problem is it depends upon what $data is (contains)?
- If $data is a simple scalar value, then there is no need to share() it in order to assign it to a shared data structure.
This is because assigning a simple scalar just copies its value into the (shared) destination.
- However, if $data is a reference to a hash or array (or nested structure of either or both), then simply sharing that reference is not enough.
This is because (as indicated above) when you share a reference to a compound datastructure (hash or array), it will (silently) empty the referenced structure!
For example:
use threads;
use trheads::shared;
## Non-shared hash assigned some data:
my %d = (1 .. 10 ); print Dumper \%d;
$VAR1 = {
'1' => 2,
'3' => 4,
'7' => 8,
'9' => 10,
'5' => 6
};
## Share a reference to that hash and assign it to a shared scalar
my $r:shared = share( %d );
## And not only will the reference point to an empty hash
print Dumper $r;
$VAR1 = {};
## But also the contents of the original hash will have been silently
+discarded
print Dumper \%d;
$VAR1 = {};
So, if as suggested by your OP code, $data contains a reference (as returned by Storable::retrieve(), then you will need to copy the contents of the referenced thing into a shared equivalent.
To illustrate (Please read the comments carefully!):
our %planets : shared;
our $response = SomeClass::TCP_IP_Response->new(@some_arguments);
[...]
lock %planets;
if (exists $planets{$some_id}) {
lock $planets{$some_id};
$response->content($planets{$some_id}->{'data'});
$planets{$some_id}->{'atime'} = time;
}
else {
my $data;
[...] # read the serialized data from disk
## Assuming $data is a reference to a *simple*, *single-level* hash
## Copy the data into a shared equivalent;
my %sharedHash :shared = %{ $data };
## And then assign a reference to the *shared* copy.
# my %el = ( 'data' => \%sharedHash,
# 'atime' => time,
# 'deleted' => 0,
# 'modified' => 0
# );
## But if you do this, *ALL THE CONTENTS OF %e1 WILL BE DISCARD*
# $planets{$some_id} = share(%el);
## So make the local datastructure shared also
my %el :shared = ( 'data' => \%sharedHash,
'atime' => time,
'deleted' => 0,
'modified' => 0
);
## Now you do not need to use shared()
## as a reference to a shared object is shared.
$planets{$some_id} = \%el;
}
And once you've placed a reference to a local (lexical) variable (shared or not) into a variable who's scope is wider, the contents of that variable (but not the name) will persist (not be GC'd) as long the reference persists.
But also note that if $data is a reference to a hash or array that contains nested references to other hashes or arrays, then you will also need to copy this nested structures manually. That is where a recursive structure traversal tool is needed.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
| [reply]
[d/l] |
hmm... i did what you advised me to do, but with a remarkable result:
my %el : shared = ( 'data' => $scalar_data,
'atime' => time,
'deleted' => 0,
'modified' => 0
);
$planets{$some_id} = \%el;
lock $planets{$some_id};
# results in an error: "lock can only be used on shared values."
--------------------------------
masses are the opiate for religion.
| [reply]
[d/l] |
The problem is not with what you have done, but rather a variation on the following bug as noted in the BUGS section of the threads::shared POD:
share() allows you to share $hashref->{key} without giving any error message. But the $hashref->{key} is not shared, causing the error ``locking can only be used on shared values'' to occur when you attempt to lock $hashref->{key}.
What that really means is that you cannot use lock on an element of a hash or array. Both the following attempts to lock an individual element fail in the same way:
#! perl -slw
use strict;
use threads;
use threads::shared;
my %h :shared = ( x => 1 );
lock $h{ x };
my @a :shared = 1 .. 4;
lock $a[ 1 ];
The best you can do is lock the entire hash or array--with all the potential performance hit that might entail. The hit can be minimised by confining the lock to as small a scope as possible. On a single cpu, this will in most cases ensure that the lock does not get persist long enough to be interupted by a task switch and so no penalty will result. It doesn't prevent the penalty on a multi-cpu machine.
Yes. I know it is ludicrous, but no one is listening.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
#! perl -slw
use strict;
use threads;
use threads::shared;
my $some_id = 1;
## Make the scalar shared
my $scalar_data :shared = 'fred';
my %planets :shared;
my %el :shared = (
'data' => \$scalar_data, ## reference to shared scalar
'atime' => time,
'deleted' => 0,
'modified' => 0
);
$planets{$some_id} = \%el;
## Lock the shared hash (%el) by indirection
lock %{ $planets{$some_id} };
## Or lock the data itself via indirection
lock ${ $planets{ $some_id }{ data } };
Seems a tad hookey, but it does allow you to lock the relevant sub-hash or piece of data without requiring you to lock the entire top-level hash.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |