Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

mysterious threads::shared behaviour

by ericatkin (Novice)
on Jan 18, 2009 at 07:56 UTC ( #737125=perlquestion: print w/replies, xml ) Need Help??

ericatkin has asked for the wisdom of the Perl Monks concerning the following question:

My problem/confusion can be illustrated with the code below:
#!/usr/bin/perl use strict; use threads; use threads::shared; my %h:shared; for (0..10) { $h{$_}=&share({}); } for (keys(%h)) { print "$h{$_}\n"; }
On my system, I get:
HASH(0x9904d20) HASH(0x9904d38) HASH(0x9904d14) HASH(0x9904d2c) HASH(0x9904d08) HASH(0x9904d20) HASH(0x9904d38) HASH(0x9904d14) HASH(0x9904d2c) HASH(0x9904d08) HASH(0x9904d20)
Now, obviously, the addresses change with each invocation, but it is always 5 unique addresses that repeat. It seems to be creating 11 distinct hashes where I can file away my scalars, but it doesn't make sense to me that there would only be 5 unique memory addresses. Now, mysteries like this always bother me, but beyond the mystery, this behavior breaks XML::Dumper as it uses the memory address to ensure that a data structure that is referenced multiple times is only dumped once. Without the threads::shared module, I get 11 distinct memory locations as I would expect as illustrated below:
#!/usr/bin/perl use strict; my %h; for (0..10) { $h{$_}={}; } for (keys(%h)) { print "$h{$_}\n"; }
HASH(0x9ea67c8) HASH(0x9ea6720) HASH(0x9ea67b0) HASH(0x9ec8578) HASH(0x9ea66e4) HASH(0x9ea672c) HASH(0x9ea5b44) HASH(0x9ea69a8) HASH(0x9ea6600) HASH(0x9ec8590) HASH(0x9ea6990)
What am I missing? Is there a good reason for this behavior? It has rendered XML::Dumper useless for me.

Replies are listed 'Best First'.
Re: mysterious threads::shared behaviour
by dave_the_m (Monsignor) on Jan 18, 2009 at 13:09 UTC
    threads::shared uses a mechanism similar to tying, so if you do $x = $h{$_}, then $x isn't a reference to a hash, its a reference to an 'LV' scalar variable, who's action on being accessed is to call the appropriate method that gets or stores a value in the real shared hash (with suitable locking). These LV scalars are temporaries created on demand and freed when no longer used, so you are likely to see address re-use.


      So, that explains it. Thank you. I worked around the XML::Dumper issue with the following code:
      my %tmp_h; for (keys(%h)) { $tmp_h{$_} = {}; %{$tmp_h{$_}} = %{$h{$_}}; } pl2xml(\%tmp_h, 'h.xml'); %tmp_h = ();
      Where can I read more about LV scalars?
        Where can I read more about LV scalars?

        Try PerlGuts Illustrated as a starting point. Search down for "SvPVLV" for the explanation for LV scalars, though you'll probably need to go back to the top and read down to understand the information presented under that heading.

        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.
Re: mysterious threads::shared behaviour
by zentara (Archbishop) on Jan 18, 2009 at 11:18 UTC
    my %h:shared; for (0..10) { $h{$_}=&share({}); }
    It does what you ask. You can only share scalars(including references). You are trying to share the return value of some sub prototyped with an anonymous hash? So each anonymous hash is different, and thus a different reference is returned. Beyond that, I'm confused too, as to what you are trying to do.

    I'm not really a human, but I play one on earth Remember How Lucky You Are
Re: mysterious threads::shared behaviour
by gone2015 (Deacon) on Jan 18, 2009 at 11:45 UTC

    Update: spoke too soon, sorry -- I'd left out the use threads.

    With use threads in I get the same as you. I notice the caveat in cpan:/threads::shared re refaddr() -- I guess that applies to stringification too. So, it seems to be a documented problem. is_shared() is recommended in place of refaddr, but I don't know how that helps you with XML::Dumper -- sorry.

    FWIW: I just tried your code and got 11 different addresses -- I have perl 5.10.0 with threads::shared version 1.14 (32 bit Win32) and 1.27 (64 bit Linux).

    In the past I have found shared() to be less than useful. You could try:

    for (0..10) { my %sh : shared ; $h{$_}=\%sh ; }
    and see if it works any better for you.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://737125]
Approved by Corion
Front-paged by Corion
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (1)
As of 2023-09-25 12:42 GMT
Find Nodes?
    Voting Booth?

    No recent polls found