in reply to Re^7: Proper undefine queue with multithreads
in thread Proper undefine queue with multithreads

Ok. The problem was that my $idle :shared = $maxNumberOfParallelJobs; was specified too early as maxNumberOfParallelJobs gets overwritten later using parameters.,

Your solution performs well and I get the idea of how this all should work together. Thank you for your patience.

Replies are listed 'Best First'.
Re^9: Proper undefine queue with multithreads
by BrowserUk (Patriarch) on Jun 06, 2014 at 11:16 UTC

    You're most welcome.

    With regard to the "race condition" suggested here. It's a red herring!

    The description:

    1. worker thread dequeues last item
    2. main thread checks pending (false)
    3. main thread checks number of busy threads (none)
    4. main thread signals workers to end
    5. worker marks itself busy
    6. worker starts processing last item

      7. fails to consider what happens at this point.

    7. once the worker processing the last item finishes, it loops back to check for another, gets undef, exits the loop and terminates.
    8. and the main thread, waiting on the join, sees it terminate and completes. Clean exit. Job done.

    There is simply no need for the over-engineered, overcomplicated solution suggested.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    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.
[reply]

      You missed the point. It shouldn't terminate in step 7!

      When I said it dequeued the last item, I meant the last item of the queue. There could be millions more items to process, but they're not going to be processed. Updated the linked post for clarification.

[reply]

In Section Seekers of Perl Wisdom