Re: Blocking on multiple threads with timeout

[Andrew Hacking <ahacking@xxxxxxxxxxxxxxx>]

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

-Andrew Hacking