|The stupid question is the question not asked|
Re^2: Synchronising threads with signals (or not)by BrowserUk (Pope)
|on Feb 23, 2013 at 07:28 UTC||Need Help??|
I see that my approach has been totally bum-over-tits so I consider this case closed :)
Hm. Just because the initial approach is bad, it doesn't mean that the over all goal is unobtainable.
Eg. This almost does what you asked for (note the Inline::C bit is only to get accurate timings; it doesn't affect what the code does):
NB: ms above is microseconds!
But note that even on my 4 core system, the 2 threads do not see the signal at exactly the same time. (also, if you leave it running, you'll see one of the limitations (a.k.a total idiocies) of the cond_var mechanism.
But that brings me back to the questions I alluded to earlier. Why have your main thread attempt to coordinate starting two other threads; and then just sit there doing nothing? Ie, why use 3 threads?
I can see that you might need to run the recorder and player from different threads, but why not:
This mirrors what you'd do manually. Switch the recorder on; switch the player on; when the player finishes; switch the recorder off.
There is plenty of scope for solving the problem; you just need to tackle it the right way.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
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.