Beefy Boxes and Bandwidth Generously Provided by pair Networks
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 ( #1020283=note: print w/replies, xml ) Need Help??

in reply to Re: Synchronising threads with signals (or not)
in thread Synchronising threads with signals (or not)

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

#! perl -slw use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'rdtsc', CLEAN_AFTER_BUILD => 0; SV *rdtsc() { return newSVuv( (UV)__rdtsc() ); } END_C use threads; use threads::shared; my $sig:shared; my $l0 :shared; my $l1 :shared; my $ts :shared = 0; async( sub { my $lockRef = shift; my $tid = threads ->tid; while( 1 ) { printf "[%5d] Waiting at: %10u ms\n", $tid, ( rdtsc() - $ts + ) / 2400; { lock $$lockRef; cond_wait( $sig, $$lockRef ); } printf "[%5d] Got signal at: %10u ms\n", $tid, ( rdtsc() - $ts + ) / 2400; } }, $_ )->detach for \$l0, \$l1; sleep 1; ## Give threads a chance to start. while( 1 ) { { lock $ts; $ts = rdtsc() }; printf "[main] signalling at: %10u\n", 0; { lock $sig; cond_broadcast( $sig ) }; sleep 3; } __END__ C:\test> [ 1] Waiting at: 7250756853 ms [ 2] Waiting at: 7250765890 ms [main] signalling at: 0 [ 2] Got signal at: 1422 ms [ 1] Got signal at: 1426 ms [ 2] Waiting at: 3361 ms [ 1] Waiting at: 6105 ms [main] signalling at: 0 [ 2] Got signal at: 1384 ms [ 1] Got signal at: 1398 ms [ 2] Waiting at: 3695 ms [ 1] Waiting at: 7011 ms [main] signalling at: 0 [ 2] Got signal at: 1362 ms [ 1] Got signal at: 1361 ms [ 2] Waiting at: 3672 ms [ 1] Waiting at: 7077 ms Terminating on signal SIGINT(2)

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:

main: start recorder thread; main: start player (in main); main: wait for player to finish; main: signal recorder thread to stop.

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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1020283]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (4)
As of 2017-07-22 07:39 GMT
Find Nodes?
    Voting Booth?
    I came, I saw, I ...

    Results (337 votes). Check out past polls.