DragonFly users List (threaded) for 2005-02
Re: Blocking on multiple threads with timeout
On Mon, 2005-02-28 at 05:04, Jonathon McKitrick wrote:
> I have a few threads that might need as long as a minute or more to
> complete and terminate. If they exceed an arbitrary time, they can be
> In Win32, there is a 'wait on multiple objects' call. I'm not sure if it
> blocks or spins, but it *does* take a timeout argument.
> Is there a similar way with pthreads that I can use that will kill the
> threads after a certain time, but without spinlocking? After a minute of
> spinning, my laptop fan kicks on, and I'd like to be a bit more reasonable
> about my CPU cycle demands. :-)
> Jonathon McKitrick
> My other computer is your Windows box.
FYI: pthread_cond_timedwait() allows your waiting thread to block on a
condition variable, which your other worker threads could signal when
they have completed. When your waiting thread awakes due to a timeout,
it can call pthread_cancel() [see WARNING] to terminate the threads
which haven't completed, followed by a pthread_join() if they were
created as non-detached threads. Also depending on the cancellation
state of the worker thread, your waiting thread may still end up waiting
indefinitely in the pthread_join().
WARNING: I have never used pthread_cancel() because its a nightmare to
write reliable code that can be cancelled at any instant. It places an
onerous burden on the software to ensure program state and resources are
managed in a way so that if the rug gets pulled, program state remains
consistent and everything gets cleaned up correctly.
Instead, you may want to re-consider the software that *allows* your
worker threads to block indefinitely, because it probably won't be
written to expect cancellation and you will then need to solve the
resource/state-management problems. I have usually found it easier to
retrofit/coerce legacy code to use a bounded timeout when performing
operations that can block indefinitely. This is much easier and more
reliable than the above high wire act, and often avoids the need for a
"manager" thread altogether.