# Make a copy of a complex data structure that is thread-shared.
# If not thread sharing, then make a 'regular' copy.
sub shared_copy
{
    my $in = $_[0];

    # Make copies of array, hash and scalar refs
    if (my $ref_type = ref($in)) {
        # Copy an array ref
        if ($ref_type eq 'ARRAY') {
            # Make empty shared array ref
            my $out = ($threads::shared::threads_shared)
                            ? &threads::shared::share([])
                            : [];
            # Recursively copy and add contents
            for my $val (@$in) {
                push(@$out, shared_copy($val));
            }
            return ($out);
        }

        # Copy a hash ref
        if ($ref_type eq 'HASH') {
            # Make empty shared hash ref
            my $out = ($threads::shared::threads_shared)
                            ? &threads::shared::share({})
                            : {};
            # Recursively copy and add contents
            while (my ($key, $val) = each(%$in)) {
                $out->{$key} = shared_copy($val);
            }
            return ($out);
        }

        # Copy a scalar ref
        if ($ref_type eq 'SCALAR') {
            if ($threads::shared::threads_shared) {
                return (threads::shared::share($in));
            }
            # If not sharing, then make a copy of the scalar ref
            my $out = \do{ my $scalar; };
            $$out = $$in;
            return ($out);
        }
    }

    # Just return anything else
    # NOTE: This will generate an error if we're thread-sharing,
    #       and $in is not an ordinary scalar.
    return ($in);
}
[download]

If you still find that doesn't work, then you may be bumping up against problems with threads under ActivePerl 5.8.4. See Re^3: New Module Announcement: Object::InsideOut.

Well, you've read my mind, apparently. If I couldn't get my in situ routine to work, the next step was going to be to copy a node from the shared hash, do the insertion work on it, then copy it back -- making sure, in the process, that all the subnodes are shared. If I go that route, your routine will come in handy. Thanks!

This, too, is an option I was considering. But I didn't know about freeze and thaw in the Storable package. (I was going to use Data::Dump and eval. Yecch!) Thanks for the pointer!

threads::shared should have provided autovivification built-in. Why make every user try to do it on his/her own?

Dave.

Just to reinforce the point, could you give some general information of how much extra space is required to share a structure.

Eg. If a structure takes 10Kb as a non-shared entity, how much would it cost to share this with say 2 other threads (3 total)? Is it 30Kb, 40Kb, 50Kb extra?

Also, if you change a leaf (scalar) within that structure, how much slower is that than in a non-shared equivalent?

Finally, does the hit of updating the other copies of the modified value come

• all at once in the context of the thread that makes the modification?
• Or incrementally as the other sharing threads get a timeslice?
• Or does the sharing thread have to defer until each of the other threads get a timeslice in order to update their copies?

  If the latter is the case, does the time the modifying thread waits for the others threads to update depend on the vagaries of the scheduler calling those threads (in competition with all other threads in the system), before the modifying thread can continue and unlock the modified scalar?

  ---

  Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

  Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

  "Science is about questioning the status quo. Questioning authority".

  In the absence of evidence, opinion is indistinguishable from prejudice.

Very roughly speaking, a shared variable is implemented internally using a form of tieing. Each thread has its own copy of the tied variable, and the real value is stored in a separate area of shared memory. When you read a variable, the tied code gets called (XS rather than perl code), which locks the real shared value, then copies its value into the thread's private address space. Similary a write to a shared variable involves copying the private value into the shared variable. So in a worst-case scenario:

my $s : shared = 'a' x 10_000;
for (1..100) {
    async { my $l = length $s; sleep }
}
[download]

would consume about 1Mb, with each thread having a cached copy of the string at the point it was accessed.

Nested structures are more complicated than that, but roughly speaking the worst-case isn't as bad as the scalar case above.

Dave.

Nonetheless, a built-in facility or function to ease the process for the disciplined programmer would've been a nice touch. The contortions that we are forced to resort to in its absence betray an obvious deficit in the pragma's original vision. I can't agree that things that "encourage bad habits" are necessarily bad. Let's face it: Perl itself encourages bad habits -- as does any tool with similar power. It's up to the user to wield that power responsibly.