in reply to Synchronising threads with signals (or not)

What’s missing from your sketchup is how the two threads are intended to work together.   Do they work “together,” e.g. one is capturing data that the other one is producing?   That’s going to make a tremendous difference in how the whole thing should be properly set-up.

But in any case ... threads shouldn’t have tight timing-expectations like you describe.   If a thread is consuming something, let it read from a queue (e.g. Thread::Queue), simply blocking on the read if there is nothing there to read yet.   Ditto, let a producer-thread push data onto such a queue and keep going on its merry way.   If someone needs to monitor the status of something, push status-messages onto some queue for the monitor to remove.   If it’s time to shut-down the child threads, send a “please shut down” command-message to that child’s queue.

Queues act like flexible, stretchy hoses, buffering away the timing dependencies and letting the threads run efficiently at full speed with little or no need to “rendezvous” with one another.

Replies are listed 'Best First'.
Re^2: Synchronising threads with signals (or not)
by BrowserUk (Patriarch) on Feb 22, 2013 at 21:03 UTC

    How can a queue help you coordinate a music recorder to record a music player?

    It cannot!


    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.
    A reply falls below the community's threshold of quality. You may see it by logging in.