I just tried using the versions you mentioned, and I still see the problem arising. I get the same results using another debian server with similar perl installation.

I then tested against my other system running perl 5.8.5 and threads/shared 1.05/0.92 with normal behaviour

Doesn't seem to be Dumper. I replaced it by some printf's and I still get the strange result. I think it may just be the way STDERR/OUT is handled on my system, and misinterpreting the output

it may just be the way STDERR/OUT is handled on my system

Another possibility. And one that is both far easier to understand and also nicely attributable to 'user error' rather than a serious internals bug.

That said, I did consider the possibility that there was some kind of interleavcing of threaded output at play here, but it is very hard to see how that could give rise to this output:

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

Not only would the output from thread 2 have to be delivered to the screen out of order--the close brace appearing before the 'b' pair--the 'a' pair from thread 1 would have to be delayed, interleaved and duplicated, and I find it impossible to dream up the scenario where the absence of resource locks could produce that effect.

You could certainly try using the tprint() sub I posted earlier in the thread (or rolling your own), but I wouldn't hold any great expectation of it providing a fix.

Then again, I cannot reproduce the problem here even if I bypass the ouput serialisation my OS does when writing to the screen, by redirecting the putput to a file. 5.8.6 or 5.10.0, I always get the same correct output. If I remove the sleeps from teh threadproc, I can indice some variablility, but nothing untoward or unexplainable.

This certainly seems to be a platform (or perhaps complier/CRT) specific problem.

---

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

I just tried using the versions you mentioned, and I still see the problem arising.

That is not good news. Please raise a perlbug against thread::shared immediately.

I'm starting to think it's Dumper's fault.

That's a distinct possibility, though the maintainers might argue that they should not be able to be the cause of such a problem.

In the meantime, try using Data::Dump and see how you fare? (But please raise the perlbug report anyway, even if it alleviates your immediate problem!).

---

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

I think I ruled out Dumper and STDERR cache:

#!/usr/bin/perl

use warnings;
use strict;
use threads;
use threads::shared;

my %hash :shared;

sub dumper {
  my $h = shift;
  my $ret = "{\n";
  while (my ($k,$v) = each %$h) {
    $ret.= "\t$k => $v\n";
  }
  $ret.= "}\n";
  return $ret;
}

sub sub1 {
  my $str = '[s'.threads->tid()."]\n";
  $str.= dumper \%hash;
  $str.= '[e'.threads->tid()."]\n";
  return $str;
}

$hash{a} = 1;
my $th1 = threads->new('sub1');
$hash{b} = 2;
my $th2 = threads->new('sub1');

my $a = $th1->join();
my $b = $th2->join();

print STDERR $a;
print STDERR $b;
[download]

Which sometimes yields:

[s1]
{
        a => 1
        b => 2
        a => 1
        b => 2
}
[e1]
[s2]
{
        a => 1
}
[e2]
[download]

And I just reproduced it on perl 5.8.5 32 and 64bit linux. Sometimes I also get:

[s1]
{
        a => 1
        b => 2
        b => 2
}
[e1]
[s2]
{
        a => 1
        a => 1
        b => 2
}
[e2]
[download]

Then again, even though we see duplicate keys, their value is correct... Maybe the problem arises when trying to cycle through all keys of the hash at the exact same time its contents are being updated: If I add a select undef,undef,undef,0.01; between the two thread spawns, I never see duplicate keys. At the worst I see normal differences between $a and $b.