Re^5: 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 -

random lines (from the file to copy) get skipped when TRACE=1, again from missed signals.
FWIW, 5.8.4 on Debian runs this correctly consistently.

My conclusion is that there's too much happening between lock, wait and signal.

Comment on Re^5: Printing to STDERR causes deadlocks. Select or Download Code

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]


Perl-Sensitive Sunglasses
	PerlMonks