pthreads. How to know if one running in a thread? pthread_self()
nab...@earthlink.net
calling pthread_self() returns a thread id, even if one running not in
a context of a pthread thread. calling pthread_self() from a single process
does return a something. (may be internal system value for the main thread?)
also pthread_self() is not defined how it failes.
so, how does one find if some piece of code is running in a pthread thread or
not? or is the question not well defined?
thanks,
Nasser
Steve Watt
>there does not seem an pthread API to tell if one is running in a thread.
On systems that support threads, every instruction is executed in a
thread. The definition of a thread is a stream of execution inside
a particular process context. There may be other threads in the
same process context, there may not.
>calling pthread_self() returns a thread id, even if one running not in
>a context of a pthread thread. calling pthread_self() from a single process
>does return a something. (may be internal system value for the main thread?)
pthread_self returns a thread id, yes. That's because there's always at
least one thread.
>also pthread_self() is not defined how it failes.
Because it can't.
>so, how does one find if some piece of code is running in a pthread thread or
>not? or is the question not well defined?
I suppose on systems that support threads other than pthreads, there
*might* be a way to tell. In general, if the pthread_* functions are
available (and functional) you're in a pthread thread.
What are you *really* trying to do? See if there are other threads in
this same process context? If so, then there is no way to tell,
because signal delivery may be handled by thread creation, or some
library may create threads that the application isn't (and needn't be)
aware of.
--
Steve Watt KD6GGD PP-ASEL-IA Packet: KD6GGD @ N0ARY.#NOCAL.CA.USA.NA
ICBM: 121W 56' 58.1" / 37N 20' 14.2" Internet: steve @ Watt.COM
Free time? There's no such thing. It just comes in varying prices...
Jeff Denham
> there does not seem an pthread API to tell if one is running in a thread.
>
> calling pthread_self() returns a thread id, even if one running not in
> a context of a pthread thread. calling pthread_self() from a single process
> does return a something. (may be internal system value for the main thread?)
>
> also pthread_self() is not defined how it failes.
>
> so, how does one find if some piece of code is running in a pthread thread or
> not? or is the question not well defined?
On Digital UNIX, there's a libc variable called, if I remember
correctly, _MULTITHREADED. If it's nonzero, you've
got the threads library in your address space. Other
vendors may have similar hooks. All are obviously unsupported
and probably unsupportable...
__________________________________________________
Jeff Denham (jde...@brighttiger.com)
Bright Tiger Technologies
SmartCluster™ Software for Distributed Web Servers
http://www.brighttiger.com
125 Nagog Park
Acton, MA 01720
Phone: (978) 263-5455 x177
Fax: (978) 263-5547
Fred A. Kulack
On IBM OS/400, we've got the following extensions to answer this question:
unsigned int pthread_is_multithreaded_np(void); == Returns number of
threads - 1.
int pthread_is_initialthread_np(void); == Returns 0 or 1
Fully supported, and completely non-portable.
Jeff Denham wrote in message <35F91E19...@brighttiger.com>...
Sushanth K Rai
> Another platform specific answer for you.
> On IBM OS/400, we've got the following extensions to answer this question:
> unsigned int pthread_is_multithreaded_np(void); == Returns number of
> threads - 1.
> int pthread_is_initialthread_np(void); == Returns 0 or 1
>
> Fully supported, and completely non-portable.
>
The same is available on HP-UX 10.20 (user space threads package) also.
Infact on HP-UX 10.20 the moment you link your application with the threads
library(libcma.1), irrespective of whether the application is using
pthread_xxx routines or not, the library would start executing the main()
function in default thread whose ID is got through pthread_self().
Sushanth
Thomas Maslen
[...]
>On systems that support threads, every instruction is executed in a
>thread. The definition of a thread is a stream of execution inside
>a particular process context. There may be other threads in the
>same process context, there may not.
Not always true: if I decide not to use threads (e.g. I don't link with
-lpthread) then on some implementations, such as the two-level implementation
on Solaris 2.x, the threads really really aren't there. (An LWP is still
there, but that's just the bottom level of the two-level implementation;
the top level really isn't there unless you ask for it at link time).
In some sense this is also true for various user-level threads implementations,
e.g. Cthreads and LWPs on SunOS 4.x.
>pthread_self returns a thread id, yes. That's because there's always at
>least one thread.
No.
Let me add one more to the list of platform-specific APIs that other people
have posted: on UI threads (including Solaris 2.x),
1 if you're the main thread,
thr_main() returns 0 if you're some other thread,
-1 if there aren't any threads
[...]
>>so, how does one find if some piece of code is running in a pthread thread or
>>not? or is the question not well defined?
[...]
>What are you *really* trying to do? See if there are other threads in
>this same process context? If so, then there is no way to tell,
>because signal delivery may be handled by thread creation, or some
>library may create threads that the application isn't (and needn't be)
>aware of.
My guess is that the original poster was trying to write library code that
is MT-safe but that also works properly if it is linked into a program that
doesn't use threads at all.
Thomas Maslen
mas...@dstc.edu.au
Dave Butenhof
> there does not seem an pthread API to tell if one is running in a thread.
>
> calling pthread_self() returns a thread id, even if one running not in
> a context of a pthread thread. calling pthread_self() from a single process
> does return a something. (may be internal system value for the main thread?)
>
> also pthread_self() is not defined how it failes.
>
> so, how does one find if some piece of code is running in a pthread thread or
> not? or is the question not well defined?
As has already been said, pthread_self() cannot fail. If _POSIX_THREADS is
defined by <unistd.h>, then the system supports threads, and pthread_self()
shall return the pthread_t handle for the calling thread. That is, if the system
support POSIX threads, all code runs in a thread, and must have a valid POSIX
thread ID. Any system failing to support this requirement does not conform to
POSIX 1003.1-1996. Implication: on any system supporting POSIX threads, all code
"runs in a thread", even if there happens to be only one thread in the process.
So, you can always assume you're "running in a thread". There's nothing else!
You may think you care whether there are also OTHER threads, but basing any code
on such tests is a dangerous idea. You're setting yourself up for a big and
painful fall.
Most modern systems, for example, support dynamic loading of libraries. It is
not only possible that the thread library may be loaded dynamically -- it's
common practice. Once that happens, additional threads may come into existence
at any time. And that brings up a secondary question -- is a process linked
against the thread library, but currently with a single thread, "threaded" or
"nonthreaded"? Those who think they want to "optimize" for the nonthreaded case
usually think they want it to be "nonthreaded". But they would need to be aware
(and carefully, thoroughly, and unerringly, make their code aware) that this
might change at any time.
Unfortunately, there's no portable/standard way to write "thread-safe" but
"nonthreaded" code. The issue of dynamic activation (or even use of threads in
shared libraries by main programs that weren't linked with threads) is
complicated and highly nonportable. On Solaris, libc preempts all of the pthread
entry points unless the main program is linked against the thread library -- you
cannot dynamically activate threads, or even use threads from a shared library
if the main program wasn't linked threaded. Even on systems where this isn't
true, proper integration usually requires that all code in the process has been
properly compiled (e.g., with _REENTRANT), and that can pose severe
complications.
Nevertheless, dynamic transitions from "nonthreaded" to "threaded" are
desirable. And, despite the fact that it doesn't always currently work well,
they're already common. Count on them! Don't ever use any interface that claims
to report whether the process is threaded, except perhaps for purely diagnostic
purposes. You're not really helping anyone -- and you, or someone else, will
surely suffer from it in the future.
/---------------------------[ Dave Butenhof ]--------------------------\
| Compaq Computer 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 ]----------------/