in reply to Re: missing values when using Parallel::ForkManager
in thread missing values when using Parallel::ForkManager

Thanks, Ken. I updated the source code, and hope this light version will explain my trouble. In fact, there was complaint from running the above code. It is "Use of uninitialized value $count". The code of this line is
my $count = $result_buffer->{$id}->{$pwm};
The missing value here indicates that this piece of code
my $count = count_pwm_num($pwm,$seq_1,$seq_2);
did not perform its function when parameters were transferred here. $pwm is from list @ciona_pwm_array. Because after executing those lines, the result will catch either 1 or 0,
if($count != 0) { $output_temp_handle->print($id); $output_temp_handle->print("\t$pwm\t1\n"); } else { $output_temp_handle->print($id); $output_temp_handle->print("\t$pwm\t0\n"); }
However, as shown in result table, several values were missed from certain rows, (row c missed value 1 in column B, row b missed value 1 in column A. The missing values have no specific pattern, and it seems randomly lost. I doubted for some reason it did not execute this code
$pm->start and next PWM;
But I do not know why. Thanks.

Replies are listed 'Best First'.
Re^3: missing values when using Parallel::ForkManager
by Anonymous Monk on Jul 07, 2015 at 02:32 UTC
    I wrote a mini code for this problem which replicates my puzzle.
    #!/usr/bin/perl use strict; use Parallel::ForkManager; my $pm = Parallel::ForkManager->new(10); foreach my $j (1..100) { LINKS: for my $i (1..10) { $pm->start and next LINKS; my $num = count($i); print $num,"\t"; $pm->finish; } print "\n"; $pm->wait_all_children; } sub count { my $num = shift; return $num + 1; }
    I expected each row should generate ten numbers from 2 to 11. However, several rows will miss values. Even worse, several rows output 11 numbers instead of 10 numbers, and have replicate, for example, 10 appear twice. Why?

      I don't get any missed numbers; I always get 2..11. I moved the wait_all_children() line above the line that prints a newline so that the output is clearer and more consistent:

      2 3 4 5 6 7 9 8 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 10 9 8 + 11 2 3 4 5 6 7 9 10 11 + 8 2 3 4 5 6 7 9 8 11 + 10 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 9 11 8 + 10 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 8 9 7 11 + 10 2 3 4 5 6 7 9 10 8 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 8 9 7 11 + 10 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 8 9 10 7 + 11 2 3 4 5 6 7 8 10 9 + 11 2 3 4 5 6 7 9 10 8 + 11 2 3 4 5 6 7 8 9 11 + 10 2 3 4 5 6 7 9 10 8 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 8 9 10 + 11 2 3 4 5 6 7 9 10 8 + 11

      Doing things in parallel means that you can't guarantee in what order they will finish. Sometimes one process takes a bit longer than the others and so the numbers appear "out of order".

      - tye        

        You and Tye reminds me of the right solution to my problem.It seems that the FileHandle was not updated in child process. I therefore created a FileHandle in each child process instead of the parent process. Anyway, it is my own understanding. If someone know it, do drop me your message.