Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^7: threads on Windows

by kennethk (Abbot)
on Feb 21, 2009 at 22:44 UTC ( [id://745570]=note: print w/replies, xml ) Need Help??

in reply to Re^6: threads on Windows
in thread 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;

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.

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

    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.

      Blocking while waiting for a lock is not blocking? You're not making sense.

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).

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://745570]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2024-04-20 20:33 GMT
Find Nodes?
    Voting Booth?

    No recent polls found