in reply to Redirecting output in Windows cmd prevents second thread from doing anything

You are misinterpreting what you are seeing. (As is everyone else who has replied.)

The "problem" is simply that given the size of your data, thread 1 has completed processing the entire array before thread 2 gets a chance to do anything.

You can prove this by increasing the volume of element in the array -- around 4000 should suffice, I simply duplicated the 1..200 20 times -- then you'll see that whilst the first couple of thousand are all processed by thread 1; after that, thread 2 gets a look-in and they start alternating.

You'll probably also notice that the logging starts getting mixed together -- partial lines from one thread being tacked onto the end of partial lines from the other -- but that's a different problem.

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". I knew I was on the right track :)
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re: Redirecting output in Windows cmd prevents second thread from doing anything

Replies are listed 'Best First'.
Re^2: Redirecting output in Windows cmd prevents second thread from doing anything
by 1nickt (Canon) on Jan 15, 2016 at 22:29 UTC

    " (As is everyone else who has replied.) "

    Even this monk in this post when he wrote: 

     ... allowing thread 1 to complete the entire workload before thread 2
+ has had a chance to start ...

    [download]
    ??


    The way forward always starts with a minimal test.
[reply]
[d/l]

      If you are selective with your quoting you can suggest anything.

      The full, relevant quote is:

      My immediate expectation is that when you redirect the output it buffers it, allowing thread 1 to complete the entire workload before thread 2 has had a chance to start

      Which I'll break down into 3 parts in reverse order:

      1. allowing thread 1 to complete the entire workload before thread 2 has had a chance to start

        No mention that the small size of the sample dataset gives only the appearance of the identified a "problem".

        Nor that if the dataset was large enough to actually warrant using two threads, then there is no problem.

      2. when you redirect the output it buffers it

        The symptoms, wrongly identified as a "problem", have exactly nothing to do with buffering. Turn buffering off and the symptoms do not change at all.

      3. My immediate expectation is

        Giving responses based upon expectations, when it took about 2 minutes to completely disprove the theory, is willfully misleading.

      And the "solution" offered to the (non)"problem"; is just completely unnecessary.

      So, yes!

      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". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[reply]

In Section Seekers of Perl Wisdom