Because I stripped down the part of my code to write a test case and kept the stupid bits that I came up with some time ago to avoid "Invalid value for shared scalar" messages without understanding why they were appearing?

For the record, I was assigning a thread object to an element of this shared hash, and using the above "strange overwriting technique" this somehow avoided the error message. Now I'm creating a "my" object reference, share it and assign it only then to the element of the shared hash.

Now this seems very complicated and I reckon I must have got lost somehow on the road. It's a bad idea to write production code whilst using modules for the first time, discovering design issues, circling back, discovering other issues... I think I'll start over ;-)

Now may I use your wisdom to get a hint on how you would design the code? Here's the big picture:

I'm simply trying to run multiple independent threads, each of which should periodically store some time-series numbers. Then a special thread would periodically take these numbers and do something with them (send them somewhere).

What I'm doing now is start the N threads plus the sending thread. Each thread handles its own infinite loop, and with its own interval. It stores its computed numbers in this shared hash. Now when the sending thread wakes up, it locks this hash, copies it to another, empties it and unlocks it. Then it can do whatever it likes with the copy

Here's the big picture: ... periodically store some time-series numbers ... and with its own interval

As overviews go, that's a little like looking at the moon through the wrong end of a telescope. You kinds know what you're looking at, but the details decidedly fuzzy :)

A few things that would clarify:

• How is the shared hash keyed?

  Ie. Does seach thread write to a separate key (or separate set of keys)?

• What does "time-series" numbers" mean?

  An example would be good.

• When the sending thread wakes up to take it copy, does it just take whatever is available, or should it only take a "complete set"?

  What I'm getting at here is that threads are non-determanistic, so there is no guarentee that all your generating threads will have been given a timeslice by the scheduler between timeslices of your sending thread. If the time interval (controlled by a sleep?) is sufficiently long, the probability is that they will all get a timeslice in the interval, but it is unwise to rely upon such probabilities if the requirement is that the sending thread should always gather a complete set.

  So, I need to know if that is a requirement? And if it is, what steps are you currently taking to ensure that?

I'd need a far clearer picture of the task before I'd be prepared to offer a design for it's solution.

---

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

• How is the shared hash keyed?

  Each thread feeds a seperate key e.g. $h->{thX}

• What does "time-series" numbers" mean?

  $h->{th1}->[[ts1,d11,...,d1N],...,[tsM,dM1,...,dMN]]
  $h->{th2}->[[ts1',d11',...,d1K'],...,[tsL',dL1',...,dLK']]
  [download]

  each thread has its own independant [tsI,[dIJ]] values

  tsI are timestamps

  dIJ are data (i.e. temperature, cpu cycles, memory usage...)

• When the sending thread wakes up to take it copy, does it just take whatever is available, or should it only take a "complete set"?

  It takes whatever is ready, and each [tsI,dI1,...,dIN] should be complete.

As for the timeslices, each thread handles its own, and yes they are pretty long - at least 15 seconds.

$ ~/perl/recycleshare3
2$VAR1 = {
          'a' => {}
        };
1$VAR1 = {
          'a' => {},
          'b' => {},
          'a' => {},
          'b' => {}
        };
$ ~/perl/recycleshare3
1$VAR1 = {
          'a' => {},
          'b' => {}
        };
2$VAR1 = {
          'a' => {},
          'b' => {}
        };
[download]

Sorry, but I would have to say that the first version of the output you've posted above is impossible. It suggests that you have managed to create a hash with duplicate keys--and that is impossible!

You're going to have to post the code that you're using, along with the versions of Perl/threads/threads::shared. Nether version of the 'corrected' code I posted could ever produce that first output barring some catastrophic corruption.

---

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

The code I used is pasted here:

#!/usr/bin/perl

use warnings;
use strict;
use threads;
use threads::shared;
use Data::Dumper;
use Config;

printf "perl: %s\n", $Config{version};
printf "gcc: %s\n", $Config{gccversion};
printf "threads: %s\n", $threads::VERSION;
printf "threads::shared: %s\n", $threads::shared::VERSION;

my %hash :shared;

sub sub1 {
  sleep 1;
  print STDERR threads->tid();
  print STDERR Dumper \%hash;
}

$hash{a} = &share({});

my $th1 = threads->new('sub1');
$hash{b} = &share({});
my $th2 = threads->new('sub1');

$th1->join();
$th2->join();
[download]

I just reproduced the result:

$ ~/perl/recycleshare3
perl: 5.10.0
gcc: 4.3.2
threads: 1.67
threads::shared: 1.14
1$VAR1 = {
          'a' => {},
          'b' => {}
        };
2$VAR1 = {
          'a' => {},
          'b' => {}
        };
$ ~/perl/recycleshare3
perl: 5.10.0
gcc: 4.3.2
threads: 1.67
threads::shared: 1.14
2$VAR1 = {
          'a' => {}
        };
1$VAR1 = {
          'a' => {},
          'b' => {},
          'a' => {},
          'b' => {}
        };
[download]