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