Thank you for reminding me about that excellent blog post by Jonathan. It was a bit ranty, but it also was a direct result of similar questions I was asking at that time. :-)

At the moment, MoarVM has a potential for crashing when more than one thread is adding a key to a hash at the same time. This is a known issue and still being debated on how to be solved.

So, to work-around the possibility of crashes, one should make sure that the hash already has all of the possible keys before starting to do the parallel run. If rewritten your code to be more idiomatic Perl 6:

constant RANGE = 10_000;
my %hash = ^RANGE Z=> 0 xx RANGE;
await do for 1..10 {
    start {
        %hash{ (^RANGE).pick }++ for ^100_000;
    }
}

say "Seen { %hash.values.grep(* > 0).elems } keys";
# Seen 10000 keys
say "Average value (~100 if threadsafe): { %hash.values.sum / %hash.el
+ems }";
# Average value (~100 if threadsafe): 91.7143
[download]

I think the constant RANGE = 10_000 is rather self-explanatory. The next line may be somewhat harder to grasp: it fills the hash %hash with a list of Pairs generated by zipping (Z) a range (^RANGE, which is short for 0 .. RANGE - 1) with a sequence of 10_000 zeroes (0 xx RANGE) using the fat-comma operator (=>)

Then we execute %hash{ ^RANGE .pick }++ for ^100_000 in 10 different threads. The (^RANGE).pick picks a random value from the range of 0 .. RANGE - 1.

The results are then shown by directly interpolating code inside a string: you can use curly braces for that.

You can use the .sum method to get a sum of values, and .elems directly on the hash to find out the number of elements

I haven't been able to get this version to crash: however, it is still not threadsafe for the reasons that Jonathan explains so well in his blog post.

If one uses the map/reduce idiom, the code would look like this:

constant RANGE = 10_000;
my %hash is Bag = await do for 1..10 {
    start {
        my %h;
        %h{ ^RANGE .pick }++ for ^100_000;
        %h;
    }
}

say "Seen { %hash.values.grep(* > 0).elems } keys";
# Seen 10000 keys
say "Average value (~100 if threadsafe): { %hash.values.sum / %hash.el
+ems }";
# Average value (~100 if threadsafe): 100
[download]

You will note that now each thread has its own hash that can get updated without any problems. The result is a list of 10 hashes that are merged into a single hash with Bag semantics. (see Sets, Bags and Mixes for more information on Bags).

A Bag is basically an object hash (so the keys are not necessarily strings) that only accepts positive integers as values. Initialization of a Bag accepts and merges anything that looks like a Pair or a list of Pairs (which is basically what a hash is in that context).

So that would be the idiom to use safely. Hope this made sense :-)

At the moment, MoarVM has a potential for crashing ... So, to work-around the possibility of crashes, one should make sure that the hash already has all of the possible keys before starting to do the parallel run. If rewritten your code to be more idiomatic Perl 6

This is rather amusing if sadly unsurprising. Having been sold Perl6 on the basis that is has all the benefits of using a bytecode VM, we now see that the VM tail is wagging the Perl6 dog.

Surely the sane advice should be: if a particular VM is unstable then stop using it and use another VM instead. There's no need to rewrite/refactor already working code just because one VM has bugs.