in reply to Re^2: a question on sharing data structures across threads
in thread a question on sharing data structures across threads

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

  1. anything holds a reference to it.
  2. 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)?

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.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^4: a question on sharing data structures across threads
by TOD (Friar) on Oct 08, 2007 at 09:00 UTC
    that's what i wanted to know. because since the data get passed in "frozen" state via tcp/ip, $data is a scalar value.
    thank you very much indeed for the competent and elaborate explanation!
    --------------------------------
    masses are the opiate for religion.
Re^4: a question on sharing data structures across threads
by TOD (Friar) on Oct 09, 2007 at 05:13 UTC
    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.

      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.

      Here's what might be considered a work-around for the limitation:

      #! 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.
        splendid idea, thx again! (although i must confess that next time i better read the fine manual to the end... ;-) )

        update, some minutes later: and if one thinks about it, the answer is pretty simple: the reference can't be locked, because it's not being shared - but the data it refers to.

        --------------------------------
        masses are the opiate for religion.