Re^7: threads on Windows

I'm glad to see continued discussion. I managed to create what I believe to be the simplest test case for this behavior:

use strict;
use warnings;
use threads;
use Thread::Semaphore;

my $gag = new Thread::Semaphore(0);
async   {
            $gag->down;
            while (<>) {
                print;
            }
        }->detach;
#close STDIN; # Comment this line for race-condition behavior
$gag->up;
my $value = async   {   return 1;   }->join;
[download]

The proper behavior for this code should be to immediately return control to the OS. In its race-condition configuration under Win32, it will usually wait for one input and parrot it back and sometimes two inputs.

Based on your earlier post, I assume your 5.10 can function w/o the use of semaphores. I'll play with it a bit more to see if the addition of instrumentation to an independent log file affects the buffering behavior, but it seems like waiting for input on a shared file handle is blocking thread creation, i.e. what you said.

Comment on Re^7: threads on Windows Download Code

Replies are listed 'Best First'.
Re^8: threads on Windows by BrowserUk (Patriarch) on Feb 22, 2009 at 06:27 UTC
It's not a "race condition"! (And it not "<> blocking thread creation".) You cannot clone the current thread whilst another thread has a (Perl internal) lock on one of the resources to be cloned. This is WAD (Working As Designed). Perl protects it's internal data structures from concurrency corruption by serialising access to them through an internal mutex. If one of the process global resources (PGR) of a spawning thread is currently in use by another thread then the cloning of the current thread will be blocked until that mutex is released. In this case, the shared PGR is STDIN--but it could be any other PGR that blocks. In the following, if you supply an argument, STDIN will be closed in the main thread, hence it does not need to be cloned in order for thread 2 through 11 to be spawned, and the program will complete immediately. If you do not supply an argument, STDIN is not closed, and when the attempt is made to clone the main thread for thread 2, the internal mutex is being held by thread 1 because it is in a blocking read state on STDIN. Therefore, the main thread is blocked until that read state is satisfied. If you hit enter, the read on STDIN in thread 1 returns, lifting the mutex and allowing the main thread to continue. A few threads will be created before thread 1 gets another timeslice, and again enters a blocking read state whilst holding the internal mutex. The main thread is once again blocked. Hit enter again and the cycle repeats. See the two sample runs after the __END__ token: `#! perl -slw use strict; use threads; async { getc while 1; }->detach; close STDIN if @ARGV; for ( 1 .. 10 ) { async { printf "Thread: %d ran\n", threads->tid; }->detach; } sleep 1 while threads->list( threads::running ); __END__ C:\test>junk Thread: 2 ran Thread: 3 ran Thread: 4 ran Thread: 5 ran Thread: 6 ran Thread: 7 ran Thread: 8 ran Thread: 9 ran Thread: 10 ran C:\test>junk 1 Thread: 2 ran Thread: 3 ran Thread: 4 ran Thread: 5 ran Thread: 6 ran Thread: 7 ran Thread: 8 ran Thread: 9 ran` [download] 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply] [d/l]
Re^9: threads on Windows by ikegami (Patriarch) on Feb 22, 2009 at 06:36 UTC
Blocking while waiting for a lock is not blocking? You're not making sense.	[reply]
Re^10: threads on Windows by BrowserUk (Patriarch) on Feb 22, 2009 at 06:45 UTC
Blocking ... is not blocking? Sorry, but you're the one not making sense! 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. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]
Re^11: threads on Windows by ikegami (Patriarch) on Feb 22, 2009 at 06:49 UTC
Re^12: threads on Windows by BrowserUk (Patriarch) on Feb 22, 2009 at 07:51 UTC
Some notes below your chosen depth have not been shown here
Re^8: threads on Windows by gone2015 (Deacon) on Feb 24, 2009 at 13:03 UTC
OK. Your test is much shorter than mine :-) I'd recommend adding `threads->yield()` (or `sleep()`) before the `async` for the child -- to ensure the "STDIN thread" has reached the `<>`. (There is a race condition there.) ... I assume your 5.10 can function w/o the use of semaphores ... Yes. It doesn't seem to matter on my system whether the `close STDIN` runs before or after the "STDIN thread" reaches the `<>` (I've tried it both ways). But I cannot say whether that's a 5.10 thing, or because I'm running a uni-processor (or both, or neither).	[reply] [d/l] [select]