Re: Inconsistent results with keys on thread shared hashes

[ikegami]

Simpler:

for my $t (1..2) {
    threads->create(sub {
        while (1) {
            my $s = join '', sort keys %testOne;
            print "$t\t$s\n" if $s ne 'ABCDE';
        }
    });
}

sleep;

You are both reading and modifying the hash — specifically its iterator — in multiple threads. You need a lock.

[izomiac]

Ok... I had no idea hash iterators were a thing... I'd always just assumed keys was a read-only function that used local variables to iterate through the hash keys, though that's probably overstating how much thought I've even put into how hashes work under the hood. Thank you, I've used the keys function so long I never would have thought I had an incomplete understanding of how it worked.

[Anonymous Monk]

A shared hash in list context (my @a = %testOne) counts as modifying its internal iterator, too? (@a size will get 10,4,12,18 or whatever). And neither such assignment nor keys built-in are "atomic" thread-wise then, and it's not a bug? Yes, using a lock helps. In scalar context it evaluates to 1, not to number of keys. Not documented anywhere, neither.