I tried with simple program to test the pthread_self() by compiling g++
and gcc .
#include <stdio.h>
#include <pthread.h>
int main()
{
printf("Thread id %lu \n",pthread_self());
return 0;
}
#gcc gt.c -lpthread
#a.out
Thread id 3086939840
#g++ gt.c -lpthread
#a.out
Thread id 3086940384
> Hi,
> I am trying to find thread id for the main from pthread_self().
> pthread_self() suppose to return 0 in Linux for main thread but it is
> returning some value.
It is impossible for pthread_self to return zero. Zero is not a
pthread_t.
> Also this return value is not unique .because it looks like compiler
> specific . Is there any reason beyond this ? or is it bug
Huh? I don't understand what you're asking.
> I tried with simple program to test the pthread_self() by compiling g++
> and gcc .
>
> #include <stdio.h>
> #include <pthread.h>
> int main()
> {
> printf("Thread id %lu \n",pthread_self());
> return 0;
> }
>
> #gcc gt.c -lpthread
> #a.out
> Thread id 3086939840
>
> #g++ gt.c -lpthread
> #a.out
> Thread id 3086940384
The '%lu' format specifier is not a valid format specifier for a
'pthread_t'. In fact, there is no way to print a 'pthread_t'.
What are you actually trying to do? If you want some type of identifier
that has a value of zero for the first thread, create one using
pthread_key_create and friends.
DS
Where do you get this information? I searched on the web for documentation
for pthread_self and in all cases it said it returned the thread id. It
said nothing about returning 0 from main. Even main will have a thread id.
"Jim Langston" <tazm...@rocketmail.com> wrote in message
news:vrVDf.457$ec....@fe04.lga...
In general, pthread_t is supposed to be an "opaque" object.
It may contain a special, recognizable value on some platforms,
but you're not supposed to depend on that.
What I would do for portability:
1. Define a global value to contain main's threadid.
pthread_t main_tid = pthread_self();
2. In your code that tests to see which thread is primordal,
use pthread_equal() function ... do not test for constants.
The Single Unix Standard:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_self.html
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_equal.html
Says nothing about 0 or 1 for thread ids.
Aside: If you are debugging your application with dbx note that
dbx assigns it's own sequential numbers to threads, for convenience
in using the debugger.
On platforms I'm familiar with, those id's are *NOT* pthread_t ids.
This may be the reason this article suggested that main had a specific
numbered thread-id.
And further ... if you're dealing with a system that has M:N
scheduling,
those user thread-ids may not be the numbers the kernel uses.
So, if you're trying to correlate output from multiple diagnostic
tools,
bear in mind there might be 3 numbering systems to identify threads:
- dbx ... simple enumeration
- pthread_self() ... the user process thread id
- kernel thread-id
pthread_t is an opaque type. It is not defined as an int although some
implementations may implement it as such. So comparing it to an int is
meaningless and not even guaranteed to compile correctly.
To get the pthread id for the main thread you execute pthread_self from
the main thread. That's it.
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software.
> please refer the link
> http://devresource.hp.com/drc/resources/portguideipf/index.jsp#threads
That link makes no sense. Since 'pthread_self' returns a 'pthread_t', it
cannot return a zero or a one. Those are integers and there is no way to
compare a 'pthread_t' to an integer or to convert a 'pthread_t' into one.
(Unless either of the platforms being discussed provides one, and I can't
find one for either of them.)
DS