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!).

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.

Maybe the problem arises when trying to cycle through all keys of the hash at the exact same time its contents are being updated:

That makes a certain amount of sense in the version above with the sleeps removed. It's quite easy to see how (without locking) that the hash iterator could be corrupted. But that does not explain the earlier versions where you have sleeps that effectively orchestrate serialisation of the writing and reading of the hash.

Yes, you should be using locking. But for locking to be the fix for the original (with sleeps) version of the code, it would mean that iterating a 2 key hash would have to take longer than not just one timeslice (in order for the other thread to have a need to lock), but longer than 1 second. And that's just silly.

A quick test shows that Perl can iterate a two-key shared hash 10 million times in just over 4 seconds:

use threads; 
use threads::shared;
use Time::HiRes qw[ time ];

my $h:shared = ( 1..4 ); 
print time; 
for ( 1..1e7 ) { 
    1 while each %h;
}
print time;

1227886927.80338
1227886932.10025
[download]

Even on a multicore box and with Data::Dumper in the mix, there's no way that the sleeping version of the code you posted could be concurrently modifying and iterating that 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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."