[Q.] How to validate a thread ID
Thomas Jensen
How can I determine if a given thread ID is valid, i.e. wether a thread
of
this ID is currently running?
pthread_self() only gives me the ID of the current thread, and as far as
I
can see, the pthreads package doesn't seem to offer any function to
access
information about the IDs of the currently running threads.
What I'm trying to do now is to use pthread_getschedparam() and invoke
it
with the thread ID I want validated. If it returns an error code, I
assume
that the thread ID was invalid. Does this approach make sense?
Is it expensive?
And, by the way, there is no way I can keep a table of the currently
running threads, believe me. However, the information I need is
certainly
available to the scheduler, so there should be a way to get at it.
Any suggestions and ideas are greatly appreciated!
Thank you very much in advance.
Thomas
--
Thomas Jensen <tsje...@vnet.ibm.com>
If possible, please reply also by e-mail. Thanks!
Patrick TJ McPhee
In article <33D51B...@vnet.ibm.com>,
Thomas Jensen <tsje...@vnet.ibm.com> wrote:
% How can I determine if a given thread ID is valid, i.e. wether a thread
% of
% this ID is currently running?
pthread_kill with a signal of 0 returns (I think) 0 if the thread is
running or if it's not running but hasn't been detached or joined (so
its resources are still floating around). It returns -1 if the ID is
invalid. So far as I can see, this is only useful if you're interested
in a detached thread, since if you've already joined to it, you know
the thread isn't there anymore.
Please note that this is the (documented) behaviour under Solaris and
AIX, but I haven't seen the Posix spec so I'm just assuming it's
the correct behaviour.
--
Patrick TJ McPhee
East York Canada
pt...@ican.net
Andrew Josey
Patrick TJ McPhee (pt...@ican.net) wrote:
: In article <33D51B...@vnet.ibm.com>,
Looks correct according the online Single UNIX Spec (a superset
of the POSIX Spec):
" The pthread_kill() function is used to request that a signal be
delivered to the specified thread.
As in kill(), if sig is zero, error checking is performed but
no signal is actually sent. "
The URL for the online specification is
http://www.opengroup.org/unix/online.html
--
Andrew Josey, #include <disclaimer.h>
For UnixWare freeware binaries, sources , and FAQs - http://www.freebird.org
Dave Butenhof
Patrick TJ McPhee wrote:
>
> In article <33D51B...@vnet.ibm.com>,
> Thomas Jensen <tsje...@vnet.ibm.com> wrote:
> % How can I determine if a given thread ID is valid, i.e. wether a thread
> % of
> % this ID is currently running?
>
> pthread_kill with a signal of 0 returns (I think) 0 if the thread is
> running or if it's not running but hasn't been detached or joined (so
> its resources are still floating around). It returns -1 if the ID is
> invalid. So far as I can see, this is only useful if you're interested
> in a detached thread, since if you've already joined to it, you know
> the thread isn't there anymore.
A call to pthread_kill with a signal number of 0 will check whether the
thread ID is valid. If it's not valid, pthread_kill will return ESRCH,
however, not -1. No pthread function, either in POSIX threads or in the
obsolete "draft 7" API currently provided with AIX, will return -1.
A thread ID is "valid" from the time it's created (sometime within the
scope of the call to pthread_create that starts it) until it has
terminated and been detached (either via the detachstate attribute
having been set to PTHREAD_CREATE_DETACHED or by a successful call to
either pthread_detach or pthread_join). There's no prohibition against
using any function (except pthread_detach and pthread_join) on a thread
that's detached. The catch is that you must ensure that the detached
thread can't have terminated. Although pthread_kill, unlike most
functions operating on a thread ID, is required to detect an invalid
thread ID, the system is allowed to "recycle" a thread ID immediately
upon termination of a detached thread -- so you might be checking the
wrong thread.
There isn't necessarily any good use for pthread_kill(<id>,0). It's
there mostly just because it mirrors the behavior of kill(<pid>,0). You
can't use it to verify whether a detached thread has terminated unless
you already know it CANNOT have terminated (because the thread ID may
have been recycled), and you can't really use it for joinable threads,
either. The ID is valid until it's been joined/detached, even if it's
terminated, so the pthread_kill won't fail; and, as Patrick says, you
presumably can know whether you've joined with the thread already. (And
if you can't you're still in trouble since a successful return from
pthread_join detaches the thread and allows the ID to be recycled.)
So the documented, supported, and fully portable behavior of
pthread_kill(<id>,0) is absolutely useless except as a curiosity.
> Please note that this is the (documented) behaviour under Solaris and
> AIX, but I haven't seen the Posix spec so I'm just assuming it's
> the correct behaviour.
I can't check the AIX documentation, but the Solaris 2.5 manpage for
pthread_kill is correct, specifying a return value of ESRCH rather than
the -1 value you described.
/---------------------------[ 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/cp/butenhof/posix.html |
\-----------------[ Better Living Through Concurrency ]----------------/
Bjorn Reese
[... Newsgroups: trimmed ...]
Thomas Jensen (tsje...@vnet.ibm.com) wrote:
> How can I determine if a given thread ID is valid, i.e. wether a thread of
> this ID is currently running?
From the pthread_kill() man page:
If sig is 0, a validity check is done for the existence of the
target thread; no signal is sent.
Mark A. Crampton
Dave Butenhof wrote:
>
> Patrick TJ McPhee wrote:
> >
> > In article <33D51B...@vnet.ibm.com>,
> > Thomas Jensen <tsje...@vnet.ibm.com> wrote:
> I can't check the AIX documentation, but the Solaris 2.5 manpage for
> pthread_kill is correct, specifying a return value of ESRCH rather than
> the -1 value you described.
>
The AIX 4.2 man page on pthread_kill states that pthread_kill "acts with
threads like the kill subroutine with single-threaded processes" and
shows valid return values of being EINVAL or ESRCH.
Patrick TJ McPhee
In article <33D5F2...@zko.dec.com>,
Dave Butenhof <bute...@zko.dec.com> wrote:
% Patrick TJ McPhee wrote:
% > pthread_kill with a signal of 0 returns (I think) 0 if the thread is
[...]
% > its resources are still floating around). It returns -1 if the ID is
% A call to pthread_kill with a signal number of 0 will check whether the
% thread ID is valid. If it's not valid, pthread_kill will return ESRCH,
% however, not -1.
I dug up the program I used to test this and both Solaris and AIX
return ESRCH. The (I think) in the first line I quote above was meant
to indicate a general uncertainty about the return codes, since I
don't have any docs here (at home). I admit it doesn't really read
that way.
% the system is allowed to "recycle" a thread ID immediately
% upon termination of a detached thread -- so you might be checking the
% wrong thread.
But will this be the case if I can guarantee that no new threads have
been created in my process in the interim? I have a situation where
I need to check that all my threads have reached a cancellation point
before I shut down a process. The problem is that this can take hours
or even days in practice, and I can't have my supervisor thread
blocking on a join call for all that time.
I was looking for something like waitpid with the WNOHANG option so I
could poll intermittently. It occurred to me that if I detached
the worker threads when I created them, and then was careful to
never start a new thread once the shut-down was started, I could
safely use pthread_kill to test for completion of all the others.
I've rejected this approach because those words `if I was careful' don't
really go with the notion of having a working, maintainable application,
and I want to know the exit status, but I'm still curious as to whether
things ought to work the way I've alluded to above.
I'm also curious to know whether there's a way to test whether a
thread is just hanging around, waiting for a pthread_join call to
end its miserable existence, so I can ensure that my joins don't
block.
Bryan O'Sullivan
p> But will this be the case if I can guarantee that no new threads
p> have been created in my process in the interim?
Do you use any third-party libraries at all in your code? If so, then
you can't make this guarantee.
p> I have a situation where I need to check that all my threads have
p> reached a cancellation point before I shut down a process.
Then get them to update some shared variable before they die off, or
something similar.
p> I'm also curious to know whether there's a way to test whether a
p> thread is just hanging around, waiting for a pthread_join call to
p> end its miserable existence, so I can ensure that my joins don't
p> block.
Nope.
<b
--
Let us pray:
What a Great System. b...@eng.sun.com
Please Do Not Crash. b...@serpentine.com
^G^IP@P6 http://www.serpentine.com/~bos
stephen
Thomas Jensen (tsje...@vnet.ibm.com) wrote:
: How can I determine if a given thread ID is valid, i.e. wether a thread
: of this ID is currently running?
how about
pthread_t id;
/* ... */
switch(pthread_kill(id, 0)) {
case 0:
/*
* thread exists
*/
break;
case ESRCH:
/*
* thread doesn't exist
*/
break;
default:
/*
* strange happenings.
*/
break;
}
[newsgroups and followups cut]
--
Stephen Parker. Department of Physics, University of York, York. Y01 5DD
ste...@stephen.uk.eu.org. Home: 01904 612699 Work: 01904 430000 ext 2282