It looks like a race condition. If the the GetData thread sets $$doneRef in the space after while ( !$done ) is evaluated, the lock on $sharedData will block and wait for a signal indefinitely.
Since these threads are in lock-step, it seems to me a simple threads->yield near the end of the main thread's while loop (or even a short sleep before the loop starts) would force the GetData thread to start first, thereby preventing the race condition from happening. Should the code get more complex and longer running, all bets would be off - it would be very difficult to prove there wouldn't be a race condition.
Have you considered using threads::shared::semaphore instead?
Update: I added sleep 1; before the loop in GetDataT, results are the loop hangs every time. Added threads->yield; before the closing brace of the main thread's while loop, succeeded every time - even with the sleep. Even though it appears to work, yield is only a suggestion to the OS, not a guarantee.
In reply to Re: Printing to STDERR causes deadlocks.
by bmann
in thread Printing to STDERR causes deadlocks.
by BrowserUk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |