|more useful options|
Re: a question on threadsby BrowserUk (Pope)
|on May 11, 2005 at 03:40 UTC||Need Help??|
Rather than starting a new thread each time you might be better using a pool of long running threads that trigger from a time taken from queue.
The number of threads required to ensure prompt service will depend upon the time they take to do what they have to do. If the time is always less than 1 second, then you could get away with a pool of 1, but if they might take longer, you'll need more:
Note how in the second run above, there were not enough threads running for the delay and so they gradually get further and further out of sync each timeslot. And also, how adding one more thread brings that back in the third run.
Also, you'll get better accuracy by sleeping for a smaller time period and checking whether the timeslot has arrived than sleeping for an absolute time. The smaller the sleep, the greater the accuracy, but it will still never be always exact (within some small descrepancy) because you have to wait for the scheduler to give the appropriate thread a timeslice.
Also, reducing the sleep below a certain minimum will greatly increase the cpu time spent polling. A tenth of a second works well on my system, giving an accuracy of < 1/10th whilst burning negligable amounts of cpu.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.