pthread_join() with a timeout?
Adam Stein
I went looking through the FAQ and DejaNews but the closest answer I could
find was an article for a non-blocking pthread_join() and I didn't see
a good answer.
I'm porting code from NT to Solaris and I need to emulate the Microsoft
WaitForSingleObject() function when called with a thread. For those not
familiar with this call, it would be like calling pthread_join() with a timeout
argument. WaitForSingleObject() returns when either of the following happens:
1) a specified thread has exited
2) a timeout occurrs
pthread_join() can wait for a thread to exit, but I also need it to come back
if the thread hasn't exited after a specified period of time. I was hoping
that there was an elegant and simple answer, but I haven't found one yet.
I was looking into pthread_cond_timedwait(), but I didn't really need all
the mutex stuff. Is pthread_cond_timedwait() the best way to do this? I
suppose I could set up atexit() calls for each new thread to affect the
condition when exiting (but that would be ONLY when the thread exits normally).
If this IS the way it's supposed to be done, can anybody point me to a small
example that sets up the conditional variable and uses it?
I also thought of maybe using pthread_kill() to see if the thread is still
around, doing a usleep() for the specified time period, then checking to see
if the thread is still around. If it is, then the timeout occurred, if the
thread exitied, then not. The only problem with this is that you are always
stuck there for the length of the timeout period (assuming the thread was
still active before the usleep()).
Anybody have any other ideas? Thanx for any info.
--
--
Adam Stein @ Xerox Corporation Email: ad...@iset.scan.mc.xerox.com
Disclaimer: Any/All views expressed
here have been proved to be my own. [http://www.csh.rit.edu/~adam/]
David McCann
Adam Stein wrote:
>
> I went looking through the FAQ and DejaNews but the closest answer I could
> find was an article for a non-blocking pthread_join() and I didn't see
> a good answer.
>
Associate a condition variable and 'exited' flag with each thread you're
using
this way. If each thread sets this flag on exit (eg at the end of its
start
routine and in cancellation handlers) you can just do a
pthread_timed_wait()
on the target thread.
That's the most portable way I can think of, although you (obviously)
have
to have control of thread creation and suchlike to do this. It's not
going
to work on OEM libraries whose threads you want to wait for.
David McCann.
=============================================================
MindWork GesmbH | Mail: mcc...@mind-work.com
Frauengasse 11/2 | Voice: +43 1 21145-6262
A-1170 Wien | Fax: +43 1 489 8237-4
Austria | URL: http://www.mind-work.com/
==============================================================
Fred A. Kulack
Adam Stein wrote in message <1998Jan30.1...@news.wrc.xerox.com>...
>I was looking into pthread_cond_timedwait(), but I didn't really need all
>the mutex stuff. Is pthread_cond_timedwait() the best way to do this? I
If you use condition variables, then you do really need 'all the mutex
stuff'. There's a protocol to using condition variables that requires the
mutex, and you need the mutex to protect whichever flag you decide to
associate with your condition. (I.e. your thread_did_exit flag).
Adam Stein wrote in message <1998Jan30.1...@news.wrc.xerox.com>...
>suppose I could set up atexit() calls for each new thread to affect the
>condition when exiting (but that would be ONLY when the thread exits
>normally).
Watch your terminology... The atexit() function is completely unrelated to
the issue you're talking about here.
David had the right suggestion. Start there:
- Associate a condition, an exited flag, and a mutex with each thread you're
waiting for like this.
- When the thread ends, (normally or in cancelation cleanup handlers) it
should lock the mutex, set the flag, signal the condition variable, unlock
the mutex, and go toes up.
- When you're timed 'joining' to the thread, lock the mutex, check the flag,
pthread_cond_timedwait(), when timeout occurs, check the flag once more,
(possibly pthread_join() or pthread_detach() if the thread is terminated),
then unlock the mutex and bail...
Dave Butenhof
Adam Stein wrote:
> I'm porting code from NT to Solaris and I need to emulate the Microsoft
> WaitForSingleObject() function when called with a thread. For those not
> familiar with this call, it would be like calling pthread_join() with a timeout
> argument. WaitForSingleObject() returns when either of the following happens:
>
> 1) a specified thread has exited
> 2) a timeout occurrs
>
> pthread_join() can wait for a thread to exit, but I also need it to come back
> if the thread hasn't exited after a specified period of time. I was hoping
> that there was an elegant and simple answer, but I haven't found one yet.
pthread_join() is nothing but an oversimplified, minimalist CONVENIENCE for the
simplest, most common, and least interesting case. You can wait for the thread to
terminate and receive from it a single void* value.
But there's nothing "magical" about it. There's a predicate (termination), a value
(the void*), and synchronization to control access to the predicate. While it may
not be implemented this way on all platforms, a perfectly good solution would be
for pthread_join to lock a mutex associated with the thread, wait on a condition
variable until the "terminated" predicate is set, and then fetch the result value
from the thread's data structure.
It's just as easy for YOU to do this, as for the thread library to do it. The only
reason to have pthread_join() at all is because there seemed to be no point to
forcing almost everyone to code this same construct. However, if you want to do
anything beyond that near-universal basic operation, you can easily roll your own.
> I was looking into pthread_cond_timedwait(), but I didn't really need all
> the mutex stuff. Is pthread_cond_timedwait() the best way to do this? I
> suppose I could set up atexit() calls for each new thread to affect the
> condition when exiting (but that would be ONLY when the thread exits normally).
> If this IS the way it's supposed to be done, can anybody point me to a small
> example that sets up the conditional variable and uses it?
Yes, you do need "all the mutex stuff", because that's the only way to ensure
synchronization and memory visibility between your threads.
There's no such thing as a per-thread "atexit", although you can get a similar
effect using thread-specific data destructors, as long as you make sure that each
thread you care about has a non-NULL value for the TSD key. Doing the data
transfer and signal/broadcast from such a destructor would have the advantage of
catching any thread termination. In order to return data, the destructor needs to
be able to find it. Since you need a non-NULL value anyway, to trigger the
destructor, it'd make sense to have the key's value BE the return data (either a
value or a pointer to a structure).
> I also thought of maybe using pthread_kill() to see if the thread is still
> around, doing a usleep() for the specified time period, then checking to see
> if the thread is still around. If it is, then the timeout occurred, if the
> thread exitied, then not. The only problem with this is that you are always
> stuck there for the length of the timeout period (assuming the thread was
> still active before the usleep()).
Well, as long as you haven't DETACHED the thread, you can use pthread_kill. But
the fixed usleep would be a bad idea. A timed condition wait would be much more
effective.
/---------------------------[ Dave Butenhof ]--------------------------\
| Digital Equipment Corporation bute...@zko.dec.com |
| 110 Spit Brook Rd ZKO2-3/Q18 http://members.aol.com/drbutenhof |
| Nashua NH 03062-2698 http://www.awl.com/cseng/titles/0-201-63392-2/ |
\-----------------[ Better Living Through Concurrency ]----------------/