in reply to Re^4: Printing to STDERR causes deadlocks.
in thread Printing to STDERR causes deadlocks.

Okay, I've run it multiple times. It hangs for me too, but randomly - about 1 out of 25 runs - more often if the machine is under heavy load. I moved the warn statements after the lock in both subs and moved the "warn m-processing" above the signal to reduce the time the variable was unlocked. That seemed to help, but how do we quantify it?

The $done race was not the only one. Looking at the TRACE output, the warn statements don't get executed uniformly. I guess hat's to be expected, since the threads run asynchronously.

However, when it hangs, I see one of two things: a missed signal or a signal being raised when the other thread isn't waiting. 

m-locking
m-waiting
t-Locking
t-Waiting
t-Setting
t-Signalling  # look ma, nobody received my signal!
t-Locking
t-Waiting     # and now we're both blocked, waiting for the other to c
+all

or (I reconstructed this second scenario from memory)

m-processing
t-Locking
t-Waiting
t-Signalling  # if a tree signals in a forest, and noone's listening
t-Locking
t-Waiting
m-locking
m-waiting     # and again, we both wait...

[download]

Now threads::shared says the following about the second condition: 

If there are no threads blocked in a "cond_wait" on the variable,
the signal is discarded. By always locking before signaling, you can
(with care), avoid signaling before another thread has entered
cond_wait().

[download]
Uh... what does it mean "with care"?

Two more random notes -

  1. random lines (from the file to copy) get skipped when TRACE=1, again from missed signals.
  2. FWIW, 5.8.4 on Debian runs this correctly consistently.
My conclusion is that there's too much happening between lock, wait and signal.

Replies are listed 'Best First'.
Re^6: Printing to STDERR causes deadlocks.
by BrowserUk (Patriarch) on Apr 27, 2005 at 17:28 UTC

    This is the bit I do not understand about the api. In your example below: 

    m-processing
t-Locking
t-Waiting
t-Signalling  # if a tree signals in a forest, and noone's listening
t-Locking
t-Waiting     <<<< Point A
m-locking
m-waiting     # and again, we both wait...

    [download]

    At point A, t has locked the shared var and goes into the wait state.

    Then m gets a timeslice, finishes processing and loops back to lock() the var. It gets the lock, but t hasn't yet released it?

    Then again, whilst m is processing, the lock it acquired is still in force, so how the hell did t manage to aquire a lock and move forward to the wait/signal/lock/wait steps?

    If it is possible to use this api to synchronise two threads access to a single var, I'd sure like to see it.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
    Rule 1 has a caveat! -- Who broke the cabal?
[reply]
[d/l]

In Section Seekers of Perl Wisdom